Author: Gregory Maxwell 2012-09-11 19:42:32
Published on: 2012-09-11T19:42:32+00:00
In an email exchange from 2012, a proposal was made to have a simpler protocol that gives all transactions hashes and allows nodes to download the transactions separately. However, downloading each transaction individually could be inefficient. It was suggested that nodes request multiple transactions at once to save bandwidth. Another proposal was to add a few additional components to the protocol to allow requests for any level of the merkle tree, but it was unclear what value this would provide, and it could result in additional costs.The issue of block size was also discussed. At the time, the block sizes were around 0.1MB, but it was questioned what would happen if Bitcoin demand started pushing that into megabytes. The limit of ~0.95MB needed to be changed eventually for Bitcoin to grow that far, but the finite size is what creates non-trivial fees. Without the fees, there is no honest economic motivation to mine with adequate computing power to provide security. If block sizes became too large, it could lead to performance issues when relaying.Bitcoin gets its value through scarcity, both in terms of the coins (there will never be more than 21 million) and the block space (which cannot be more than 1MB). Blockchain scarcity is not a problem as transactions can be made outside of it in a secure and distributed manner. The idea of confirmations being slower was always expected due to the stochastic consensus and fee-based security support. Changing the block size limit would be just as difficult as changing the 21 million limit since all Bitcoin node software must be replaced with incompatible software, and it would be economically risky if done wrong. If the block size ever increases, the message format used for relaying the larger blocks will be the smallest of the issues being discussed.
Updated on: 2023-05-19T04:09:37.230162+00:00