Published on: 2015-06-17T16:17:22+00:00
In an email thread from June 1, 2015, Adam Back suggests taking a wait-and-see approach while addressing spam and improving decentralization metrics in Bitcoin. He proposes incrementally increasing the block size as a temporary solution while working on long-term scalability improvements. Tom Harding questions the lead time required for this approach and shares a graph showing the distribution of block sizes over time. Richard Moore is listed as a contact in the email.It is noted that increasing the block size can cause problems for old clients who may not understand the difference between various block sizes. However, SPV wallets are not affected by this issue, and fully validating wallets can be updated with a small code change. The writer clarifies that the argument about huge blocks and data centers was made by Satoshi, not the person being addressed. They had previously written the scalability page for Bitcoin in 2011, which stated that the network could scale to higher transaction rates assuming nodes run on high-end servers. The author feels that their words have been misinterpreted.The discussion revolves around businesses seeking more transactions and the implementation of compatible wallets. Extension blocks are mentioned as a way to enable opt-in and incrementally deployable options. Exchanges could encourage users to adopt wallets supporting larger block sizes by charging fees for smaller transactions. The author emphasizes that extension blocks and lightning networks are unrelated, and there is a tradeoff between security and volume in block size. Different people have different requirements, and the proposal aims to facilitate experiments with larger blocks without conflicting with those who prioritize decentralization. The author suggests waiting and observing whether the block size should remain unchanged for a year or implementing incremental changes while also focusing on long-term scale improvements.Another email conversation involves a wallet developer expressing concerns about updating software to support extension blocks. They worry that if an exchange supports such blocks and a withdrawal is made to a wallet that doesn't understand them, the money might never arrive, potentially causing a disaster. The developer emphasizes the importance of reliable payments and compatibility among wallets. They disagree with the idea of a Lightning-style approach, citing risks, inflexibility, and reduced decentralization. The developer also raises concerns about relying on companies as sounding boards and disregarding the opinions of those providing services to the community.In a separate email conversation, Adam proposes that opt-in block size increases are a preferable solution to hard forks for increasing transaction capacity. He argues that extension blocks offer forward and backward compatibility, allowing businesses in need of more transactions to implement them in their wallets. This approach gives users the choice to opt-in while maintaining security and gaining access to higher transaction per second (TPS) rates at the expense of increased centralization. Adam points out that the decentralization metrics are worsening, making it an unfavorable time to exacerbate the situation. Extension blocks are deemed less centralizing than a fixed block size of 9MB because non-spam transactions would likely occur off-chain until lightning-like systems are established, which would introduce central systems prone to custody and security failures.
Updated on: 2023-08-01T13:00:10.956516+00:00