Published on: 2017-05-03T22:45:40+00:00
The discussions on the bitcoin-dev mailing list revolve around finding solutions to reduce failure probabilities, increase the number of full nodes, and decrease the storage requirement for running a full Bitcoin node. Various proposals are suggested, including storing random percentages of less commonly available blocks, using Forward Error Correction (FEC) codes like Reed-Solomon codes, allowing pruning of old transactions, and implementing small nodes with Reed-Solomon coding. These proposals aim to improve network health, scalability, and accessibility while addressing security and reliability concerns.One proposal suggests adding a third mode for nodes, allowing them to signal that they keep the last 1000 blocks. This would be beneficial for pruned nodes, as they could partially serve historical blocks instead of serving all or none. Another proposal suggests a "random pruning mode" for nodes, which stores a random set of blocks and drops random blocks as disk space runs out. However, this proposal has disadvantages due to the potential inability to download certain blocks, particularly with active adversaries.The aim is to decrease the resource requirements for running a full node, which is crucial for decentralization, security, and protection against political interference. A suggestion is to compactly indicate which blocks a node has, allowing each node to store a subset of blocks. However, missing even a single block could pose a significant problem. Financially incentivizing nodes is a complex issue, as it may lead to malicious actors automating deployment. However, offering rewards for long-term commitment could be a potential solution.There are concerns about the default setting of pruned nodes in bitcoin-core, with claims that it could become problematic. The priority should be to increase the number of full nodes with incentives for people to run them. In a previous discussion, there was a suggestion to compactly indicate which blocks a node has, and it was recommended that each node store the last few days' worth of blocks.David Vorick proposes a solution called "small nodes" to increase the number of users running full nodes. Small nodes would only need to store about 20% of the blockchain using Reed-Solomon coding. Each small node has a permanent index and stores a piece that corresponds to its index. The full block can be recovered by connecting to six random small node peers. Vorick believes this solution would greatly benefit decentralization without putting pressure on archival nodes.Disk space consumption is identified as a significant factor preventing more people from running full nodes. Pruned nodes are currently the best alternative, but this puts pressure on archival nodes. The proposed solution is a new node type called a "small node" that stores only 20% of the blockchain. Small nodes use erasure coding to store fragments of blocks and can recover the entire blockchain by connecting to six random small node peers. There are challenges in preventing denial-of-service attacks and ensuring the correctness of the stored pieces. Implementing small nodes would require a non-trivial amount of code but could significantly increase the percentage of users running full nodes and create a healthier network.
Updated on: 2023-08-01T20:28:26.315407+00:00