Published on: 2015-06-15T18:14:56+00:00
In a discussion on the Bitcoin-development mailing list, there is a debate about whether to increase Bitcoin's 1MB block size limit or not. One user suggests a hard fork to remove the limit, but others express concern about the potential impact on the market price and suggest alternative solutions.One proposal is a soft-forkable extension-block approach, while another suggests a hard fork and merge-mining approach to allow both the original 1MB limited bitcoin and a forked version with no block size limit to coexist. A developer named Rebroad suggests a merge-mining solution where a forked Bitcoin with no block size limit could be mined alongside the original Bitcoin. This would preserve diversity and avoid risk to people's investments. The Bitcoin core developers can implement a patch to allow the chain to fork at a set point, splitting bitcoins into the new and old versions. However, concerns remain about branding and potential confusion between the two versions.In another email thread, developer Mike Hearn discusses the importance of decentralization and the trade-off between using centralized services and decentralized approaches in the block size debate. Some argue that the benefits of decentralization are low compared to adding additional features. Third-party services are providing what developers need to build great apps, even if it fails to meet perfect cryptographic ideals.The conversation also touches on the issue of trustless querying of the UTXO set and the compromise of querying multiple peers for more decentralization and robustness. However, some developers prefer outsourcing to trusted services for ease of use.There is a discussion about O() notation and the majority of users running web or SPV wallets instead of relaying nodes. Eric Lombrozo expresses concern about the lack of validation among nodes and its acceptability as a feature of the protocol.The article mentions the trend of using web2.0 technology in wallets/services and the preference for outsourced services due to their developer-friendly features. There is a call for acceptance of different approaches to decentralized app development.The conversation also includes discussions about StrawPay's micropayments system, the block size increase code in Bitcoin XT, and various scaling and decentralization proposals.The issue of validation cost in blockchain is discussed, with suggestions for better data structures and algorithms rather than simply increasing block size.Finally, there is a discussion about Jeff Garzik's outline draft BIP 100, which proposes a block size increase with an explicit 32MB ceiling and an option for users to opt into further growth. There is a recognition of the need for a measured pace of transition and market input.Overall, the discussion highlights the ongoing debate within the Bitcoin community about the best way to handle the block size limit, scalability, and decentralization while considering the potential impact on the market and user experience.In a discussion about Bitcoin scalability, there is disagreement over whether there should be a growth limiter on block size increase. The conversation involves proposals such as Greg Maxwell's difficulty adjust and paying bitcoins to future miners as alternatives. Adam Back suggests that conversations about Jeff Garzik's draft BIP 100 should be held on the mailing list. He highlights issues with "paying with difficulty" and proposes layering models, smart-contracts, and protocols like lightning to improve scalability.Eric Lombrozo states that the real issue with scalability is the cost of validation, not complexity. Algorithmic improvements are needed, but a hard-fork takes time to deploy.Adam Back believes that much of the industry is built on outdated technology and companies need to invest in integration and coding for scalability. Mike Hearn expresses concern about outsourcing services and not running full nodes, suggesting that technologists should focus on building incrementally deployable solutions.The conversation also touches on the idea of raising the block size limit and the potential consequences of scrapping existing software. Adam shares his thoughts on Jeff Garzik's BIP 100 and proposes changes to the original proposal. He emphasizes the importance of avoiding interventionist subsidies and providing links to related discussions and proposals.
Updated on: 2023-08-01T13:17:27.957013+00:00