Author: Matt Whitlock 2015-06-02 21:26:27
Published on: 2015-06-02T21:26:27+00:00
The proposal discussed in this context suggests a voting procedure to increase the block size limit. The goal is to create a simple voting procedure that can be easily aggregated over each 2016 block period. The proposal suggests adding an output at tx.vout[0] with OP_RETURN data of the format "OP_RETURN {OP_1 or OP_2}" to the coinbase transaction to vote for or against increasing the block size limit. Not voting is equivalent to voting against the increase. If there are more than 1008 blocks that voted to increase the block size limit in a 2016 block round, then the max block size increases by 500 kb. The proposal highlights important properties of this simple voting, including that it's not gameable via broadcasting transactions and miners don't have to bloat their blocks artificially just to place a vote for larger block sizes. The chain up until the point that this goes into effect may be interpreted as just lacking votes to increase the block size. However, the objection to this type of proposals is always that miners would want larger blocks than the rest of the network could bear. Thus, handing control over the block size limits to the miners might lead to centralization of Bitcoin in the hands of a few large mining pools. The proposal author acknowledges that we can't trust all miners, but we have to trust that >50% of them are honest for the system to work. This system makes it so that altering the maximum block size requires >50% of miners (hash power) to vote to increase the consensus-limit. The author suggests picking one proposal and running with it, stating that this is an important time in Bitcoin's history.
Updated on: 2023-06-09T21:57:59.549020+00:00