Improving the consensus-sensing mechanism for protocol upgrades

[mmeijeri]

When BIP-16 was adopted, there was a sort of informal vote. Miners were asked to embed their vote in the coinbase transactions of blocks they mined and to switch to the new rules once a majority supported it:

On February 1, 2012, the block-chain will be examined to determine the number of blocks supporting pay-to-script-hash for the previous 7 days. If 550 or more contain "/P2SH/" in their coinbase, then all blocks with timestamps after 15 Feb 2012, 00:00:00 GMT shall have their pay-to-script-hash transactions fully validated. Approximately 1,000 blocks are created in a week; 550 should, therefore, be approximately 55% of the network supporting the new feature.

BIP 0016

Users / owners / merchants didn't have a direct say. Indirectly they did get to vote with their feet and their transaction fees of course, but in order to avoid accidents it's good to have a mechanism that ensures you don't end up on the minority branch of a fork accidentally, while still influencing the outcome. I thought it might be useful to have a way for people who own or spend bitcoin to have a direct vote.

I'm thinking of something like embedding a vote (the hash of "I vote for/against BIP-XXX", perhaps with a hash of the BIP itself included in the string) in transactions using OP_RETURN. There are complications with this, and it probably not a good proposal as is, but I'd like to explore if we can think of improvements that would turn it into one.

Instead of requiring a majority (or supermajority) of coinbase-based votes in the last N blocks, you could require a double majority, i.e. a majority of coinbase-based votes as well as a majority of ordinary transaction-based votes.

To deal with ballot-stuffing, you could add up votes from the UTXO set at a pre-specified date, weighted by amount of BTC, perhaps limited to outputs belonging to transactions that were entered within the three months immediately preceding the cut-off date.

Complications include the hassle of doing this with coins in cold storage, privacy concerns, censorship concerns.

[1713425019]

1713425019

[1713425019]

1713425019

[theymos_away]

When BIP-16 was adopted, there was a sort of informal vote. Miners were asked to embed their vote in the coinbase transactions of blocks they mined and to switch to the new rules once a majority supported it:

That was not a vote. See:
https://bitcointalk.org/index.php?topic=93513.msg1033244#msg1033244

Voting, in addition to being a terrible way of making decisions, would be pointless here. The majority of mining power can do softfork changes regardless of any vote, and users can force softfork changes only with a hard fork, which probably requires more than a majority of users anyway. You can't change this without significantly changing how Bitcoin works.

[mmeijeri]

That was not a vote. See:
https://bitcointalk.org/index.php?topic=93513.msg1033244#msg1033244

"The topic or board you are looking for appears to be either missing or off limits to you."

[mmeijeri]

Voting, in addition to being a terrible way of making decisions, would be pointless here.

It wouldn't be a real vote, more like a non-binding opinion poll to help establish a consensus without accidents and to coordinate timing. Anyone would still be free to fork, but it would be a conscious decision in the knowledge that it represented a minority.

The majority of mining power can do softfork changes regardless of any vote, and users can force softfork changes only with a hard fork, which probably requires more than a majority of users anyway. You can't change this without significantly changing how Bitcoin works.

I know how Bitcoin works. Something like the mechanism I'm suggesting would be more important for a hardfork, but could still be useful for a softfork. For a softfork the point of the "vote" would not be to stop miners from imposing their will, but to offer an additional tool to help figure out what the economic majority wants without accidents. Hence the word consensus-sensing.

[onemorebtc]

one problem is that miners can place as many transactions in their own block as they like without paying anything.

this would give them way to much voting power.

i dont see a way for users to vote directly, but miners may use something like this to tell the network if they are ready for a planned hardfork or if they are not - and this could be used automatically to let bitcoin core decide when a planned hardfork could start.

[mmeijeri]

one problem is that miners can place as many transactions in their own block as they like without paying anything.

I'd look at the UTXO and weigh each output of a transaction marked with a "vote" with the amount of BTC in that output. This way subsequent transactions could override earlier votes.

[onemorebtc]

one problem is that miners can place as many transactions in their own block as they like without paying anything.

I'd look at the UTXO and weigh each output of a transaction marked with a "vote" with the amount of BTC in that output. This way subsequent transactions could override earlier votes.

the uxto is not synchronized between all nodes, so this could lead to different results. but i think thats ok as it should not have a big error margin.

but subsequent transactions could not override earlier ones: one of the main reason for blocks is to order transactions. what could work is, that every node only considers transactions in a block as a vote which he saw in his uxto previously. but i dont think the benefit to have voting would justify for a client to remember his uxto longer than necessary.

btw: what about a use case?
my opinion is that voting is only useful for new features which would hardfork the chain if not enough miners support it. if thats the only use-case it would be enough to just let miners vote with their coinbase as it was done with your example.

[mmeijeri]

Bumping this as it seems relevant to the current discussion about a block size increase.