Proof of Work: email versus bitcoin I have read 

"Hashcash is a proof-of-work algorithm that requires a selectable amount of work to compute, but the proof can be verified efficiently. For email uses, a textual encoding of a hashcash stamp is added to the header of an email to prove the sender has expended a modest amount of CPU time calculating the stamp prior to sending the email. In other words, as the sender has taken a certain amount of time to generate the stamp and send the email, it is unlikely that they are a spammer. " (https://en.wikipedia.org/wiki/Hashcash)

Then, in bitcoin, it seems natural that the senders engage in the proof of work instead of miners. Why it is not so?
Proof of work helps to solve the issue of transaction ordering: miners must create blocks that contain an order of transactions, and each block builds upon the last. Thus all bitcoin transactions are ordered, and this is required in order to resolve any potential transaction conflicts.

As an example: in the case of a double spend, which transaction is actually valid, and which should be discarded? A simple way to resolve this question is to say "the first transaction is valid, the second is not", but this solution requires the network to be in consensus regarding the ordering of all transactions. 

In the case of email, ordering of messages is not critically important, so the inclusion of a POW has a slightly different primary function: to increase the cost of sending an email, in order to discourage spam messages. 


  
    Then, in bitcoin, it seems natural that the senders engage in the proof of work instead of miners. Why it is not so?
  


Transaction ordering is important, but keep in mind that it is not trivial to reliably keep a decentralized network in consensus. Each transaction could include a proof-of-work, but this alone is not enough to give the transactions a well-defined order. Proof-of-work establishes a way to ensure resources were spent, but on it's own is not sufficient to establish an ordering of data. 

Bitcoin solves this by grouping transactions into blocks, and each block references the one before it. You can imagine this as a sort of 'decentralized clock', where the smallest increment of time is one block. For transactions to function similarly, each transaction would have to reference the one before it, thus establishing an order. This would lead to a whole host of latency issues, higher rates of 'orphan transactions', potential for spam and DOS attacks, etc.