Published on: 2015-09-04T15:40:26+00:00
There has been a recent change in the Bitcoin protocol that reduces the block size to 2MB. This change is likely due to concerns about an increase in the attack vector if BIP101's allowance for larger block sizes were implemented. Simon Liu suggested grabbing code from BIP101, which permits block messages greater than 2MB while retaining the current limit of 2MB on other network messages. The 32MB limit was patched a few months ago and can be found on Github. The limit is designed to keep message sizes small enough that they can be serialized in memory. There is discussion about lifting the 32MB limit and having the ceiling auto-raise according to a factor starting one year from now. The delay time could also be longer depending on how long it takes to fix the message size issue across all implementations.A suggestion has been made to grab some code from BIP101, which permits block messages larger than 2MB while retaining the current limit of 2 MB imposed on other network messages. The 32 MB limit was patched a few months ago and can be viewed on GitHub. The limit is in place to keep message sizes small enough to be serialized in memory. It has been suggested that the 32 MB ceiling should be auto-raised according to an exponential factor starting in 2017. The factor could be 1.5, and the delay time could be longer if it takes longer to fix the message size issue across all implementations.The 32MB limit has been set in the code to keep message size small enough for serialization in memory. A suggestion was made to lift the limit and implement an auto-raise ceiling according to an exponential factor starting from a year from now. The hard limit ceiling should be 32 MB till 2016-2017 and then it should be 32*((currentYear-2018)*1.5) MB after that. The factor could be 2 as in BIP-101 but a more conservative approach is suggested. The delay time can also be increased if needed.A discussion was held regarding the hardLimit range, which floats between 1-32M, inclusive. It was questioned if the 32MB limit still exists anywhere in the code since it reinstates a legacy limitation. It was explained that the message size limit aims to minimize storage required per peer and if a 32MB block size is required, each network input buffer must be at least 32MB, which makes it difficult for a node to support a large number of peers. It was suggested that sending messages containing only part of a block will make it possible to receive parts of a block from multiple sources. It was suggested that using MB resolution instead of byte resolution would use up fewer bytes in the coinbase. Even with the +/- 20% rule, miners can vote for the nearest MB. Abstains were suggested to count for the status quo, and votes that are out of range should be clamped.Regarding the new hardLimit, votes were suggested to sort from lowest to highest for the last 12,000 blocks. Blocks that do not have a vote are considered a vote for the status quo. Votes are limited to +/- 20% of the current value. The raise value is defined as the vote for the 2400th highest block (20th percentile), and the lower value is defined as the vote for the 9600th highest block (80th percentile). If the raise value is higher than the status quo, the new limit is set to the raise value. If the lower value is lower than the status quo, the new limit is set to the lower value. Otherwise, the size limit remains unchanged.In a message to the bitcoin-dev mailing list, Dave Scotese raised the issue of varying interpretations of the term "1M" in relation to bytes used by different people within the industry. He believes that "megabyte" should be used to refer specifically to 2^20 (1,048,576) bytes and that "Kb" should always mean 1024 bytes, rather than being rounded up or down. To clarify the situation, he suggested that the spec needed to nail down these details. The IEC standard, meanwhile, is to use the prefix MiB for 2^20 bytes.The Bitcoin community is currently discussing the implementation of BIP 100, a hard fork that would allow for an increase in block size. However, some members of the community are questioning why certain topics are being avoided in these discussions. One member suggests focusing on functionality rather than deployment methodologies to ensure a quick inclusion of the proposal.The discussion also delves into the proposed 75% rule, which some argue is meaningless since there are no invalid Version 4 blocks.
Updated on: 2023-08-01T15:57:54.790290+00:00