Bitcoin Forum
December 05, 2022, 03:15:19 PM *
News: Reminder: do not keep your money in online accounts
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Improving the consensus-sensing mechanism for protocol upgrades  (Read 1333 times)
mmeijeri (OP)
Hero Member
*****
Offline Offline

Activity: 714
Merit: 500

Martijn Meijering


View Profile
November 12, 2014, 03:21:12 PM
Last edit: November 12, 2014, 03:34:33 PM by mmeijeri
 #1

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:

Quote
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.

ROI is not a verb, the term you're looking for is 'to break even'.
According to NIST and ECRYPT II, the cryptographic algorithms used in Bitcoin are expected to be strong until at least 2030. (After that, it will not be too difficult to transition to different algorithms.)
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1670253319
Hero Member
*
Offline Offline

Posts: 1670253319

View Profile Personal Message (Offline)

Ignore
1670253319
Reply with quote  #2

1670253319
Report to moderator
1670253319
Hero Member
*
Offline Offline

Posts: 1670253319

View Profile Personal Message (Offline)

Ignore
1670253319
Reply with quote  #2

1670253319
Report to moderator
theymos_away
Member
**
Offline Offline

Activity: 82
Merit: 26


View Profile
November 12, 2014, 05:16:46 PM
 #2

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 (OP)
Hero Member
*****
Offline Offline

Activity: 714
Merit: 500

Martijn Meijering


View Profile
November 12, 2014, 05:19:58 PM
 #3


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

ROI is not a verb, the term you're looking for is 'to break even'.
mmeijeri (OP)
Hero Member
*****
Offline Offline

Activity: 714
Merit: 500

Martijn Meijering


View Profile
November 12, 2014, 07:34:32 PM
 #4

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.

Quote
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.

ROI is not a verb, the term you're looking for is 'to break even'.
onemorebtc
Sr. Member
****
Offline Offline

Activity: 266
Merit: 250


View Profile
November 12, 2014, 08:05:11 PM
 #5

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.

transfer 3 onemorebtc.k1024.de 1
mmeijeri (OP)
Hero Member
*****
Offline Offline

Activity: 714
Merit: 500

Martijn Meijering


View Profile
November 12, 2014, 08:17:25 PM
 #6

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.

ROI is not a verb, the term you're looking for is 'to break even'.
onemorebtc
Sr. Member
****
Offline Offline

Activity: 266
Merit: 250


View Profile
November 12, 2014, 08:29:02 PM
 #7

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.

transfer 3 onemorebtc.k1024.de 1
mmeijeri (OP)
Hero Member
*****
Offline Offline

Activity: 714
Merit: 500

Martijn Meijering


View Profile
May 31, 2015, 11:07:47 AM
 #8

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

ROI is not a verb, the term you're looking for is 'to break even'.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!