bitcoin-dev

Combined summary - Scaling Bitcoin with Subchains

Combined summary - Scaling Bitcoin with Subchains

The email thread discussed various proposals and ideas to scale blockchain technology, specifically focusing on Bitcoin.

One proposal suggested merge-mining, where the parent chain includes the hashes of its children's headers as transactions. This would incentivize parents to validate their children by collecting fees from them. Another proposal suggested a treechain-like subchain system, where miners can only mine certain parts of the tree to ensure fairness. However, no solid design has been developed yet for this approach.The discussion also touched on the possibility of increasing the block size limit through a soft fork with sidechains in the future. Sidechains were seen as a way to achieve horizontal scaling and sharding while maintaining the primary security parameters of the main chain. However, some participants argued that sidechains do not offer a useful compromise between validation and non-validation. They believed that validation should either be done for everything or not at all. Concerns were also expressed about the complexity and delays introduced by sidechains.There was also a debate about the importance of validation in blockchain technology. Some argued that validation is necessary for all transactions, while others suggested probabilistic verification or validating a random subset of scripts. The consensus was that sidechains are not a solution for scaling up blockchain technology.The participants discussed the advantages and disadvantages of different proposals, such as storing only headers or full blocks, filtering transactions based on criteria, and the risk of pruned nodes. They emphasized the need for a proper system that ensures decentralization, security, and scalability.The email thread focused on a proposal by Andrew Poelstra to scale Bitcoin without increasing the block size. The proposal suggested creating child chains linked to the main blockchain, which would increase the network's total capacity for storing transactions. The proposal aimed to promote decentralization by allowing participants to produce the necessary devices without relying on centralized powers.While some developers supported the proposal and offered suggestions for implementation, others raised concerns and objections. Specific sidechain problems mentioned in previous research were brought up as potential issues. Gavin Andresen objected to the proposal without providing an explanation for his objections. Mike Hearn expressed concerns about the costs and limitations of hard drives and proposed tape backup as a more viable storage option. He also questioned Poelstra's motivations, wondering if they stemmed from philosophical beliefs or self-interest.In response to Andrew's concern regarding Bitcoin's reliance on hard disk storage, another participant suggested using tape backup technology instead. They provided a link to an article about Sony's development of tape technology capable of storing 185 terabytes per cartridge. While sharing the cost of a blockchain archive with others was not seen as a significant concern, caution was advised against validating the chain on compromised computers.To address the block size limit increase problem, the author proposed a partitioned system with ten 1 MB chains below the main chain. This arrangement would allow larger transactions to be processed through the top chain, while middle and small-sized transactions would be verified by one of the middle or bottom chains respectively. Regular users would be able to store lifetime transactions on a 5 TB drive. Additionally, the author suggested that people should be able to validate all blocks rather than just a pruned part to counter compromised machines. This would enable individuals to access information about Bitcoin transactions comparable to large data centers, potentially exposing government or corporate corruption.In terms of implementation, the author proposed keeping the current chain as the top chain and creating ten level 2 chains that also store Bitcoin. To incentivize people to continue mining on the level 1 chain, the author suggested forcing it into the protocol that anyone mining on level 2 must also mine on level 1, with a similar requirement for subsequent levels. Even if people stop using level 1, any owned bitcoin in the level 1 chain can be transferred to level 2 while still maintaining 1 MB blocks due to the partitioning scheme. The author acknowledged having only a high-level understanding of the Bitcoin protocol but believed that his proposal could work with a soft fork.In conclusion, the email thread explored various proposals and ideas to scale blockchain technology, particularly focusing on Bitcoin. Different approaches, such as merge-mining, treechain-like subchains, and sidechains, were discussed, along with their potential benefits and challenges. While no definitive solution was reached, the participants acknowledged the importance of ongoing research and development in this area to address scalability, validation, mining decentralization, and security concerns.

Discussion History

0
AndrewOriginal Post
May 20, 2015 02:55 UTC
1
May 25, 2015 18:15 UTC
2
May 28, 2015 02:16 UTC
3
May 28, 2015 02:34 UTC
4
June 13, 2015 14:39 UTC
5
June 13, 2015 17:55 UTC
6
June 14, 2015 06:55 UTC
7
June 15, 2015 17:05 UTC
8
June 15, 2015 17:09 UTC
9
June 15, 2015 17:15 UTC
10
June 15, 2015 17:18 UTC
11
June 15, 2015 18:00 UTC
12
June 15, 2015 18:01 UTC
13
June 16, 2015 15:23 UTC
14
June 16, 2015 18:17 UTC
15
June 16, 2015 18:43 UTC
16
June 16, 2015 19:04 UTC