Bitcoin User Voting

Merriam-Webster defines “vote” as:

a : a usually formal expression of opinion or will in response to a proposed decision; especially : one given as an indication of approval or disapproval of a proposal, motion, or candidate for office
b : the total number of such expressions of opinion made known at a single time (as at an election)
c : an expression of opinion or preference that resembles a vote
d : Ballot

Note that this definition does not include anything about votes being bound to actionable outcomes as a result, only that opinion is expressed in a formal manner. By this definition, BIP009 gives miners (or more accurately mining pools) the ability to vote on Bitcoin proposals. There is currently, however, no formal facility for Bitcoin users to vote.

Transactional Voting

I believe the fundamental problem with the governance of Bitcoin right now stems from the lack of a way to accurately quantify user sentiment. This problem is exacerbated by several factors:

  • Censorship of major communication channels (real or perceived)
  • Chinese miners not sharing the same channels as the majority of the user base
  • More attention paid to the loudest users, not the largest users (cult of personality, viewpoint spamming, sock-puppets, etc.)
  • Unquantifiable, inaggregable data produced from these communications is worthless in accurately measuring sentiment
  • Self-selection of communication channels in which the vast majority reinforce opinions, distorting individual perception of the aggregate stance (echo chambers)

As the block reward subsidy decreases and users begin to pay the miners a higher percentage of their income, it becomes increasingly important that the miners are aware of the desires and preferences of the users that pay their transaction fees. It is vital that these preferences are censorship resistant and can be weighted by patronage (in the form of transaction fees paid).

Fortunately, we already have a censorship resistant platform that is easily weighted by transaction fees paid, the Bitcoin blockchain itself. A wallet feature could be coded to allow the hash of a fully or partially completed standardized ballot as an optional additional OP_RETURN of each transaction, allowing any user to vote their transaction fee for or against any number of proposals they choose. This opt-in voting mechanism would allow users a method to communicate their preference to the miners (and community at large) in a clear, efficient, quantifiable manner. Because the tx (again, optionally) has an additional output, there is a cost associated with casting a vote, eliminating spam sentiment. Because the sentiment can be weighted by the tx fee paid, it’s trivial to determine what the bulk of non-apathetic active on-chain users think on any subject… including commercial actors.

The votes can be tallied as tx fee weighted integral time windows extending into the past from the most recent block + the current mempool. In this manner, you could see a 24-hour, week, month, and year snapshot of all participating users over the period.

Effects on the network

A “standard” pay-to-public-key-hash transaction with one input and two outputs is 226 bytes. This new opt-in voting mechanism would add about 10% (20–30 bytes) to the size of this transaction. If all of the transactions in a block were of this type and had votes included, this would decrease the effective block size by about 10%. This is the absolute worst case scenario. Not all transactions are as small as 226 bytes, so the effective block size reduction could only ever be as high as 10%. This is a small price to pay to be able to securely and accurately signal the miners. Wallet software could easily be configured to add this voting output and most Bitcoin full node software can be configured to prune this data out after the fact.

Miner Vote Manipulation

While it would be just as impossible for miners to change any vote as it would be to change the recipient of a Bitcoin transaction, there are several ways they could attempt to interfere with the voting process.

A miner may attempt to censor a transaction expressing something they disagree with, but doing so would cost them the difference in fees between that tx and the next most profitable one. Additionally, the censored transaction would still be visible in the mempool and count as a vote whether or not it is accepted in a block; actually given the time window, attempting to censor a vote in this manner would only make it count over a longer period of time. Spamming the mempool with low fee txs would also prove useless as the vote is weighted by tx fee and anything below a threshold so as not to be confirmed can be safely ignored (and likely dropped from the mempool).

A miner may attempt to manipulate the aggregate vote counts by sending themselves large fee transactions in a block that they mine, which costs them nothing. Doing so would allow them to substantially alter the aggregate vote count at virtually no cost. However, when a miner mines their own transaction, they typically do not broadcast their transaction to the network before the block they solved is broadcast. If they did, they would risk their own block being orphaned or another miner collecting their fee. Nodes can be made to validate that a transaction was in their mempool for at least X seconds before being included in a block in order to make the determination as to whether that vote counted or not. This rule would discard a number of valid honest votes, but given the Poisson distribution of blocktimes, the odds are fairly equal that exclusion would happen to any given transaction and should not substantially effect the aggregate total. Any data about vote validity can be safely pruned from all nodes after a relatively short amount of time to enable offloading of the data to external systems.

Conclusion

Of course, miners (and everyone else for that matter) are under no obligation to follow these preferences, but at least everybody will be aware of them, right now it’s a complete guessing game. Luke Dash Jr. actually put up a strawpoll recently. He believes the result to be invalid due to manipulation, which almost certainly occurred to a degree on both sides. This is not a sound basis for miners, developers or anybody to make decisions on. Likewise, node count is completely vulnerable to Sybil as has been proven. Transactional voting allows those who participate in the system to express their opinions in a verifiable, proportionally weighted manner.

There are still details to figure out. Who would control any list of ballot items? How would sentiments be impartially categorized hierarchically for aggregation? (ex. Bigger Blocks -> Hard Fork -> BU vs. Bigger Blocks -> Soft Fork -> SegWit) Would a system of tags be sufficient? What about translation issues for multiple languages? I’m confident these things can and will be fleshed out into a coherent sentiment expression system that will more readily enable resolution of disputes on the direction of the protocol. If anybody else would like to work toward creating a BIP to include this functionality, I would welcome it.

This mechanism gives bitcoin media and users the ability to have an objective view of real user sentiment. After all, it is transactions that ultimately provide economic incentives to miners providing security on the network. If miners are truly acting in their long-term best interests, then they have a need to know what the users really care about. Without this mechanism, the only definitive way to track sentiment is a falling bitcoin price. By then, it might be too late for miners to react.