Why Bitcoin should have voting, and what a voting protocol should look like

Bitcoin should have voting

A successful protocol needs a strong network effect, which requires as large a number of economically relevant actors to participate as possible. People will be more likely to join Bitcoin if it has the features they want. Voting is a way to measure what people want, and make that knowledge public.

Forking changes to the protocol are less dangerous and more likely to succeed the more the more widespread the accurate belief that there is consensus is. Voting is a way to make the fact that the knowledge about what people want is public… public. This is a sort of like dating. Sara likes Lisa. Lisa likes Sara. This is good, but not that powerful yet. Now suppose that Sara knows that Lisa likes Sara. This is better. Now suppose that Sara knows that Lisa likes Sara, and Lisa knows that Sara likes Lisa. This is better still. Now suppose that Sara knows that Lisa knows that Sara likes Lisa, and Lisa knows that Sara knows that Lisa likes Sara. The odds of something interesting happening are are much improved.

The type of users that form the basis for Bitcoin’s long term stability and health need a way to coordinate deployment of changes to the protocol not just to make improvements, but more importantly to respond to attacks. For example, let’s say (hypothetically) that there were some kind of vulnerability inherent in the Proof of Work that enabled an ASIC manufacturing company to design hardware that worked less efficiently by default, but could be put into a special secret configuration that would make it substantially more efficient. If there is a conflict between the users of Bitcoin, and the miners, I think most of us would want the users to win. Voting gives them a way to coordinate a counter attack. This helps avoid the scenario where most people can understand that an attacker is abusing the system, but the attacker is controling the other machinery of protocol change.

Voting should have high turnout

You want high turnout, otherwise the vote does not actually represent the preferences of most people. Perhaps the best way to achieve high turnout is to make it easy to vote. Users rationally understand that their individual vote is not that important, but not devoid of importance, and therefore worth at least a little time and effort.

For example, every wallet could have a ballot screen that users could fill out, and then the wallet automatically cast votes matching that ballot. When new initiatives achive some sort of threshold level of importance, the wallet could pop up a dialog box notifying the user and asking their opinion. Deciding not to vote should be considered a valid option, but people should be at least notified of the important debates.

Voting should resist gaming or corruption

Clearly sibyl resistance is important, but in a pseudonymous system that is tricky.

Satoshi apparently intended to rely on using hash-power to imbue Bitcoin with sibyl resistance, but that experiment failed, because efficiency of scale has concentrated the majority of hash-power into the control of a few people, rather than in the diffused “one CPUone vote” described in the white paper. Hash-power is still good, though, because those few people have interests that are substantially (though not perfectly) aligned with the interests of Bitcoin’s users.

The ideal sybil resistant signal would not have an efficiency of scale. It would not get cheaper to produce the more of it you produce. In fact, it would be nice if it got cheaper the more people are involved, and more expensive if just one person tries to purchase it.

The things that have that quality are things that people ordinarily have about them for some other purpose. For example, if you could measure “proof of shoes” you would have an attractive sibyl resistant metric. The more people you include, the more shoes come along for free — but one person attempting to buy shoes must spend a lot of money, and then must deal with all of those shoes somehow.

Two things Bitcoin can easily access that are like this are:

Stored Value

One of the things Bitcoin is good for is storing value, and people storing value are users worth caring about. It makes sense to use “time stored” and “amount stored” as multipliers for this metric.

Block Space

The other major thing Bitcoin is good for is transferring value, and block space is the scarce resource that this consumes. Votes can be attached to a particular transaction, and weighted according to how many bytes the transaction occupies.

Unfortunately there is the potential for custodians to abuse these metrics by voting with the coins of their users. As a cultural norm, custodians must be encouraged to participate honestly in the voting process, by giving ballots to their customers and allowing them to control the voting power of their coins. To the degree that custodians fail to do this — maybe they would pay a price in lost business? If custodians do hijack the votes of their customers, perhaps the size of the influence could be estimated and factored into the evaluation of votes. Fortunately, even misbehaving custodians represent a party with some expertise, and an interest in the success of Bitcoin, and distinct wishes from miners and from influential developers.

There is also the unfortunate potential for people to sell their votes. Perhaps we can rely on the honesty of the community, and the fact that an individual vote would not be worth paying very much for? Perhaps some magical cryptography could make it so that you can vote, and your vote ends up in the total, but it is impossible for you to prove what you voted for?

Votes should not be able to be censored. The same peer-to-peer broadcast network that broadcasts transactions should probably be used to broadcast votes. Full nodes should store vote information that might be relevant in the future.

Voting should impose minimal burden on full nodes

If full nodes are going to take on the responsibility of tracking votes, then votes must be designed to not burden full nodes. Since votes must be authenticated, and we are already signing transactions anyway, I think it would be economical to include the vote as an optional part of the transaction. For example, the vote could be done with OP_RETURN, and then scored based on how many bytes the transaction is, how many bitcoins are being moved, and coin age.

Voting should involve a minimum loss of privacy

Voting is probably going to involve a loss of privacy, because your votes come through as a signal in your transactions. Means should be sought to minimize this effect by aggregating votes together somehow and making it unclear which transaction links to which vote.