Published on: 2012-06-18T10:14:41+00:00
In 2012, Alberto Torres discussed a similar idea he had previously described and provided a link to his prototype. He mentioned that Gavin had left a comment on his talk page, which he hadn't seen before. Alberto believed that Armory would be the ideal client to implement this idea but wanted to wait until it could run on his laptop with 2GB of RAM. He disagreed with Peter Todd's suggestion of implementing it in the Satoshi client instead of Armory. Alberto expressed his willingness to help after summer if the implementation was still pending. He also apologized to Peter for mistakenly sending him a private message and didn't understand his concern about "unbalancing" the tree. The proposed idea required miner support, as miners typically use either the Satoshi client or custom code. Implementing it in Armory wouldn't provide an easy upgrade path for those miners. However, using the hash tree could be implemented in any client, and a significant amount of code would be shared between calculating and using it, making implementation in the Satoshi client logical.In an email exchange, Alan Reiner clarified the differences between his proposal and Alberto Torres's earlier proposal for a similar idea. Both proposals consisted of two major components: (1) the method for creating unspent-TxOut-tree roots/fingerprints for verification, and (2) using an alternate blockchain to maintain and distribute those fingerprints. While Torres proposed a different tree structure and placing the fingerprints in the main chain header, Reiner's proposal avoided a blockchain fork by utilizing a separate blockchain. This approach could be implemented without causing disruption and offered nearly the same security as changing the protocol without hard-forking. Alberto Torres had described a simpler and more efficient version of the idea on the Bitcoin Wiki page in January 2012, suggesting that Armory would be the ideal client for implementation. Peter Todd raised concerns about deliberate unbalancing of the tree by using addresses with chosen hashes. One potential solution could be to discard any new address with a hash deeper in the tree than a certain level, indicating it was likely chosen to unbalance the tree. However, this rule would only affect individuals playing games and wouldn't impact others, as the coins could still be spent using a non-pruning client to an acceptable address that can later re-spend on a pruning client.A user named DiThi expressed interest in implementing an idea for Bitcoin blockchain compression on the Bitcoin.it wiki. In response, Peter Todd commented on Alan Reiner's Bitcointalk post regarding the same topic. Reiner's proposal involved using a tree data structure to organize all unspent-TxOuts on the network. The root of the tree would communicate its "signature" between nodes, while the leaves would correspond to addresses/scripts. The data at the leaf represents a root of the unspent-TxOut list for that address/script. To maintain the security of the tree signatures, they would be included in the header of an alternate blockchain secured by merged mining. Peter Todd questioned how people could prevent intentional unbalancing of the tree using addresses with chosen hashes. He suggested a rule that discards any new address with a hash deeper in the tree than 10*log(n), indicating it was likely chosen to unbalance the tree. This rule would primarily affect individuals playing games and would not impact unrelated parties. Additionally, Todd mentioned considering a comparison function that works last bit first, considering the popularity of firstbits.In a forum post about blockchain compression, Alan Reiner proposed using a special tree data structure to organize all unspent-TxOuts on the network. The root of this tree would communicate its "signature" between nodes, while the leaves would correspond to addresses/scripts. The data at the leaf would be a root of the unspent-TxOut list for that address/script. This proposal offers the same compression as the simpler unspent-TxOut merkle tree but also allows nodes to download just the unspent-TxOut list for each address in their wallet and verify that list directly against the block headers. This enables even lightweight nodes to obtain full address information with only a small amount of downloaded data. Concerns were raised about deliberate unbalancing of the tree using addresses with chosen hashes. One suggestion was to discard any new address with a hash deeper in the tree than 10*log(n), indicating it was likely chosen to unbalance the tree. While this rule would prevent individuals playing games from spending their money, it would not affect unrelated parties. Another suggestion was to use a comparison function that works last bit first, which may be advantageous given the popularity of firstbits.In a forum post on bitcointalk.org, Alan proposed the use of a special tree data structure to organize all unspent-TxOuts on the network and communicate its "signature" between nodes without disrupting the main network.
Updated on: 2023-08-01T03:40:47.804443+00:00