Quote from: Mike Hearn on July 11, 2011, 07:53:28 PM

By the way, if you're interested in delegated voting, I wrote a paper on using it in a democracy some time ago:

https://docs.google.com/document/pub?id=1jidmNJHWAtsPLCUD7EPPm8jOEV93kSXbZOMycqCWOyA

I think delegating voting is a great idea. I'm less convinced that it would work for replacing hashing in the block chain, but it might.

Some more problems for you to consider:

If I control a key with 10 delegators, then I spend that key to 10 new keys, what happens to the delegations? Does it make sense for a key to have fan-out (ie 1 key to delegate to 10 other keys)? Do you split the value evenly or not?
How do you efficiently detect and resolve delegation loops? ie, key A delegates to B, B delegates to C and C then delegates to A? You have to do this efficiently because otherwise setting up new delegations is a way to DoS the system. Note that detecting cycles in a large graph is slow, Tarjans algorithm is O(number of edges). If each key in the system takes part then every new address in the system potentially makes setting up new delegations harder. As the number of keys in the system grows without bound over time, that could be an issue
Keys are owned by end users who may or may not know/care about the inner workings of their currency. How do you get new users to delegate appropriately?

It should be possible to run a parallel block chain based on proof-by-stake, but using the same transactions. It could be done with an adapted Bitcoin software. Once such a chain was up and running you could compare the results vs the existing chain.

I don't have the time/energy to do this myself.

Thanks for the link!

Please forgive all the parentheses in the following...

The first two problems you listed I think can be avoided by treating votes just like bitcoins, but having "election cycles" to compensate for their irretractablility. For every election cycle (measured by some fixed number of blocks that is limited by the cost and time of running an election), every bitcoin address (or a uniquely determined address, so that bitcoin-containing private keys don't have to be network facing) is issued an equal number of "votecoins". (Can actual blockchain-recorded transactions be avoided for this issuance? Can it be done by an understanding that spends from the determined votecoin address up to the amount contained in the determining bitcoin address at the start of the election cycle are allowed during the the election cycle?) During the rest of the election period, the network will accept votecoin transactions only for those issued during the current election cycle, until the end when some fixed number of addresses containing the most votecoins are elected to be the "representatives" during the next election cycle.

I'm not sure how resource intensive this search for the top votecoin containing addresses would be.

Perhaps voter participation could be incentivized using some portion of the transaction fees and newly issued bitcoins. I'm reluctant to propose schemes to do this, though, since all the ones that I can think of don't really produce the right incentives, and also create perverse ones. The larger bitcoin holders obviously have an interest in delegating their votes, but hopefully a really simple UX (vote delegation needs to be automated every election cycle according to user inputted delegates and weightings) and some peer pressure/annoying requests from the client/P. Diddy would be enough to motivate the rest. Then again, maybe it won't matter if a bunch of the bitcoin-poor don't care enough to vote.

Notice that the public nature of the votecoin transaction history would help keep the delegates honest/effective.

Also note that storage requirements shouldn't be an issue since votecoin transactions from old election cycles don't need to be held on to.

Miners still seem to be necessary to keep time and bundle transactions, but the hashing power/reward they require could possibly be minimized the elected representatives' ability to regulate/make recommendations in the block selection process.

And if all the representatives are really doing is making recommendations to miners, then wouldn't only the miners have to be checking their signatures, usually? This could allow for a much greater diversity of representatives, since the miners are already geared to accommodate higher overhead than clients. I figure the only time the clients would need to check the signatures of the representatives is if the miners wanted to ignore the representatives en masse, creating a longer fork, and the clients wanted to ignore this longer fork. But this might become too likely an attack vector if a significant amount of the overall hashing power of the miners is made obsolete by this system.

And if it's just recommendations, then would any of this require a separate blockchain/breaking change to the protocol? Can the votecoin rules (their periodic creation and finite trading period) be accommodated somehow into the existing protocol?

Edit: From Mike, "There is a method of batch verifying ECDSA signatures that's much faster than normal. It might change the economics of what you want to do: http://www.springerlink.com/content/h758580006764h26/ "