Author: jl2012 at xbt.hk 2015-08-29 19:03:57
Published on: 2015-08-29T19:03:57+00:00
In a response to a revised proposal for increasing the block size of Bitcoin, Btc Drak expressed skepticism about any pay-to-increase proposals due to difficulty predicting game dynamics and determining appropriate penalties. Btc Drak agreed with a cap in the rate of change and maximum possible size, which is already part of BIP100. Instead of requiring a higher difficulty, Btc Drak suggested requiring miners to burn their coinbase reward or send penalty to OP_CHECKLOCKTIMEVERIFY. It is a better idea to allow mining of a bigger block immediately, but using block size as a vote may encourage filling up a block with garbage which does no good for anyone. Therefore, you need to look at both the actual block size and the coinbase vote, and always take the bigger value to determine the penalty and max block size of the next round. The original proposal allowed miners free reign to increase block size, but Btc Drak argued that this goes against a key design of Bitcoin's security model. The problem can be solved by introducing a hard cap on block size. Btc Drak proposed an initial upper limit of 8MB, so under his proposal, the block size would be flexible between 1MB and 8MB. An alternative methodology to voting in the coinbase would be to change the vote to be the block size itself. Miners could pay extra difficulty to create a larger block, and every 2016 blocks, the average or median of the last 2016 blocks would be calculated and become the new maximum block size limit. This would retain incentive to collude to increase the block size while being free to propose decrease. However, it would still require an upper block size limit in order for full nodes to retain control. Any proposal without an upper limit is going to break the security model as full nodes give up some oversight control over miners.
Updated on: 2023-06-10T20:54:11.356724+00:00