I've got an idea, and I'm wondering if it's been discussed/ripped apart here yet:

I'm wondering if as bitcoins become more widely distributed, whether a transition from a proof of work based system to a proof of stake one might happen.  What I mean by proof of stake is that instead of your "vote" on the accepted transaction history being weighted by the share of computing resources you bring to the network, it's weighted by the number of bitcoins you can prove you own, using your private keys.

For those that don't want to be actively verifying transactions, and so that not all private keys need to be facing the network, votes could be delegated to other addresses via some kind of nonstandard Bitcoin transaction.  In this way, voting power would accumulate with trusted delegates instead of miners.  New bitcoins and transaction fees could be randomly and periodically distributed to delgates, weighted by the number of votes they've accumulated, thereby incentivising diversity of the delegates and direct voters.

If the implementation could be done, it proved to maintain at least a similar level of privacy and trustworthiness, and it only minimally complicated the UX, I'm thinking that a proof of stake based fork could out-compete a proof of work one due to much lower transaction fees, since its network wouldn't need to support the cost of the miners' computing resources.  (Note that the vote delegation scheme has bandwith/storage overhead that would offset these savings by some amount which would hopefully be relatively small.)

Some other potential improvements this system could offer:

• Possibly quicker, more definite confirmation of transactions, depending on how it can be implemented.
  
• The "voting power" may be more trustworty, since it would accumulate in a bottom-up fashion via a network of trust, instead of in the somewhat arbitrary way it accumulates now.  (Note the potential problem of vote-buying here.)
• It would remove the physical point of failure of bitcoin mining equipment, which can be confiscated or made illegal to run.
• It could be used to provide stakeholders a means of making their voices heard (via the delegated voting system it establishes) when it comes to proposals for software updates and protocol changes.

Anyway, I just wanted to throw the idea out here to see if there are any obvious reasons why it couldn't be implemented, and to hopefully spark a discussion amongst those better qualified than me.

Cheers.

Wikileaks recently tweeted a reply (http://www.twitlonger.com/show/b8qli4) to a news article spreading FUD about Bitcoin.  In it they suggested Bitcoin "be augmented with a sub currency that has fixed time spend retractability if it is to be successful as a safe storage (as well as exchange) currency for the average person".

I was thinking the purposes of this could be accomplished by the client putting a fixed time delay on sends.  Of course, the user could always have the option to force transactions immediately.

If the recipient needs proof that the sender indeed has the necessary funds to send in the meantime, a message could be signed using the private key associated with an address containing them.

This would also provide some protection against "fat finger trades".

Am I understanding their concerns correctly?  Does this address them, effectively?

Edit: I guess part of their concern is theft.  Hopefully this can just be sufficiently mitigated by better security features in the client.

Here's an article on a company that crowdsources jobs to a worldwide mobile workforce: http://www.technologyreview.com/business/26651/?p1=A5.  They do jobs via text messaging.

Notice that they have to send many small payments all over the world, reaching a huge number of people, and also that they've previously paid people in Linden dollars and are therefore clearly open to using alternative currencies.

Anybody who's good at selling Bitcoin feel like getting in contact with them?  Bruce Wagner?