Published on: 2017-04-03T03:13:52+00:00
The scalability of Bitcoin transactions was discussed on the bitcoin-dev mailing list. It was noted that using spentness bits scales linearly compared to swapping digest leafs with empties, which can scale logarithmically but increases storage requirements. The limitation of 8 to 12 layers corresponds to an MMR proof length of 512 to 768 bytes if a 32-byte hash and spentness bits are used. However, making memory commitments smaller would increase CPU requirements and proof size. Full nodes can cache the top layers or remember a root per block to make proofs smaller.Using spentness bits in merkle tree hashes has limitations. Increasing the DLH_REQUIRED beyond 8 has diminishing returns. With a 32-byte hash and spentness bits, pruning is limited to 8 to 12 layers, resulting in an MMR proof length of 512 to 768 bytes. The growth rate of the MMR depends on the number of txos added. Adding 12E6 delayed utxo only txos per year leads to a growth of about 1.5MB (or 5MB) per year, while adding 200E6 txos per year leads to a growth of about 27.5MB (or 80MB) per year. This puts a limit on potential gains through pruning. Increasing the block size may require switching from spentness bits to changing digest nodes to empty nodes.In a discussion between Bram Cohen and Praxeology Guy, the idea of "The TXO bitfield" was presented. This idea suggests changing how the MMR data is modified on spend by moving from changing leaf nodes to changing a node closer to the root. This allows for commitments on the entire TXO set. However, Praxeology Guy still prefers the MMR structure if only UTxOs are added after a long delay. The index changes when delayed additions happen. Bram Cohen appreciated the idea and clarified that it is different from the Patricia Tree for bitcoin txos.Bram Cohen shared his approach to research and development, emphasizing the exploration of interesting ideas and collaboration before making decisions. He expressed his reservations about the Patricia Tree for bitcoin txos, stating that it may be too much work compared to other options. However, he clarified that he wasn't saying the design is bad or won't work but that he personally isn't interested in it at this time.The use of MMR data structure for transaction output (TXO) commitments was discussed in a Bitcoin development discussion. It was suggested that wallets should only keep information relevant to their own spendable coins and maintain the changing MMR proof for their old coins. However, wallets need to know the spentness status of close relatives in the MMR tree to construct a valid MMR proof. An alternative solution called the TXO bitfield was proposed, which would allow wallets to track only the proof of position of their TXO, avoiding the need to keep track of other data.In an email thread, a user suggested committed bloom filters as a solution to similar issues without needing a growing list of spent outputs. Praxeology Guy argued that wallets still need to know the spentness status of close relatives in the MMR tree to construct a valid MMR proof. Bitcoin nodes could keep a spentness status list to address this issue and prevent DoS attacks. However, there was some confusion in the email subject.In summary, the discussion on the scalability of Bitcoin transactions focused on the use of spentness bits and the limitations of the MMR data structure. Different proposals, such as the TXO bitfield and committed bloom filters, were put forward to address the challenges of tracking spent outputs and constructing valid proofs. Bram Cohen emphasized the importance of exploring ideas and collaborating in the research and development process.
Updated on: 2023-08-01T20:12:13.958943+00:00