Proposed alternatives to the 20MB step function [combined summary]



Individual post summaries: Click here to read the original discussion on the bitcoin-dev mailing list

Published on: 2015-06-01T11:46:30+00:00


Summary:

The ongoing debate and proposals regarding the block size limit in the Bitcoin network have been highlighted in the context. Various suggestions have been made, including making the block size limit a function of the number of transactions in the mempool, implementing dynamic scaling within a certain range, and introducing a consensus protocol for block sizes. The discussion acknowledges the need to balance scalability with decentralization and inclusivity.Gavin Andresen has proposed implementing a big increase in block size over time and seeking support from miners and infrastructure companies to run alternative versions of Bitcoin. However, there is disagreement on whether the block size should increase or remain constant, and how to measure merchant and exchange acceptance of bigger blocks.Mike Hearn suggested that the current 32mb cap on block sizes could be changed to at least some multiple of the maximum block size allowed. Another suggestion was to incorporate the required functionality into the merkle block message, allowing for sending headers messages with one header and merkleblock messages with a maximum of 1MB per message.The topic of block size and transaction throughput in Bitcoin was further discussed, with concerns raised about artificially limiting the network's organic growth. Gavin Andresen proposed a 20mb limit as a reasonable compromise, but also emphasized the importance of planning around global factors, rather than just American buying habits. Doubling the block size daily was considered imprudent, and a logarithmic increase in difficulty every 2016 blocks was suggested instead.There was a conversation about changing default settings for Bitcoin miners, with Gavin Andresen expressing skepticism towards this idea. He suggested a rule of "larger of 1MB or 2x average size" as a better option.Gavin Andresen also shared his opinion on fee pressure in the network, stating that block propagation should be made faster to eliminate technical reasons for miners producing small blocks. However, he emphasized that developers should not decide whether fees are too high or low.The fear associated with a maximum block size of twenty in Bitcoin was mentioned, with concerns raised about artificially throttling organic network growth. The discussion also touched on the balance between scaling and maintaining network stability.There were discussions about potentially setting the max size to be 20 times the average size instead. Different ideas were proposed for calculating the maximum block size, including using the median or average size of recent blocks.In terms of unspent transaction outputs (UTXOs), concerns were raised about incentives for miners to include more UTXOs in blocks. Suggestions were made to exclude UTXOs before a certain count and to store them as a fixed digest. There were also discussions about the difficulty of cryptocurrency mining and its impact on transaction fees.The article by Justus Ranvier proposes a solution where the block size is determined by the price of fees and the willingness of users to pay them, allowing for greater price discovery and alignment of incentives among network participants.During discussions about the maximum block size for Bitcoin, different proposals have been put forward. Joel Joonatan Kaartinen suggested using "bitcoin days destroyed" as a measure of demand for space in the blockchain, but Matt Whitlock pointed out flaws in this method. Whitlock argued that it does not account for future changes in bitcoin velocity and may not be relevant when large amounts of bitcoins are moved to new addresses.Gavin Andresen also proposed using the bitcoin days destroyed in transactions included in the block to determine the maximum block size. This suggestion has potential for scaling and maintaining a constant fee pressure. However, concerns were raised about its accuracy in reflecting the demand for blockchain space in the distant future when Bitcoin is more widely adopted. Further explanation is needed to ensure everyone understands the purpose of this proposal.In another discussion, various ideas were raised for determining the hard block size limit of Bitcoin. One proposal was to base the limit on bitcoin days destroyed, while another suggested allowing miners to vote on the limit. A third idea proposed making the limit a function of the blockchain length. Matt expressed support for the first proposal, as it utilizes existing data and eliminates the possibility of a mismatch between conscious votes and behavior. He cautioned against immediately jumping to a 20 MB limit, believing that it would avoid solving the problem in a controversial way.There are proponents and critics of the fixed 20 MB cap, with arguments presented for and against it. While it is the simplest solution currently proposed, it is acknowledged that it is not perfect. The speaker hopes for a less traumatic chain forking process and recalls a previous discussion about scheduling a fork every year to provide predictability. However, if things go well, there is no reason why the 20 MB limit would be permanent.In summary, discussions have taken place regarding the maximum block size for Bitcoin, with suggestions ranging from using "bitcoin days destroyed" to allowing miners to vote on the limit. The ultimate goal is to find a scalable and secure solution that supports the growth and adoption of blockchain technology.


Updated on: 2023-08-01T12:30:25.361158+00:00