Protocol-Level Pruning [combined summary]



Individual post summaries: Click here to read the original discussion on the bitcoin-dev mailing list

Published on: 2017-11-17T19:07:04+00:00


Summary:

Bryan Bishop, a Bitcoin developer, recently shared his thoughts on UTXO set commitment proposals in a bitcoin-dev post. He provided various links to resources such as previous discussions, bitfields, and source code proposals related to delayed TXO commitments, rolling UTXO set hashes, and the usefulness of TXO commitments. However, Bryan acknowledged that he was uncertain whether the recipient of his message had already explored these proposals. In conclusion, he posed a question about the possibility of categorizing these discussions by topic for easier accessibility.In response to an email from Marc, who expressed interest in a seemingly simple idea that may have already been discussed, Bryan shared several links to previous proposals for UTXO set commitment. These proposals included TXO bitfields, delayed TXO commitments, rolling UTXO set hashes, and more. Additionally, he mentioned the availability of numerous other resources, including source code proposals. Bryan's contact information, including his website and phone number, was also provided in his email signature.It appears that the speaker, Bryan, is unsure if the recipient has reviewed prior UTXO set commitment proposals. Consequently, they offer bookmarks pertaining to UTXO set commitments, TXO bitfields, delayed TXO commitments, the usefulness of TXO commitments without requiring a soft-fork, and rolling UTXO set hashes. They further note the existence of additional resources, such as source code proposals. Bryan introduces himself by name and provides his website and phone number for contact purposes.Marc, another Bitcoin developer, introduced the concept of protocol-level pruning (PLP) as a means to significantly reduce the size of the blockchain and facilitate on-chain scaling. The idea involves serializing the UTXO set in a standardized manner and publishing its hash in the block header, thereby committing the blockchain to it. When a new node joins the network, it would solely download the block headers and identify the most recent block containing the UTXO set hash, subsequently obtaining the UTXO set from peers. Nodes would serialize and verify that their UTXO set hash matches the one published in the blockchain every 576 blocks. Currently, the serialized UTXO set occupies approximately 3GB, while the entire blockchain amounts to about 150GB. Hence, implementing PLP could reduce the data stored by full nodes by a factor of roughly 50. To avoid hashing the complete UTXO set every 576 blocks, the UTXO set serialization could be accomplished using a sparse Merkle tree, enabling on-the-fly recomputation of the hash as new blocks are mined. Although a regular Merkle tree could suffice, sparse Merkle trees offer greater efficiency. With PLP, all full nodes within the network could transition to this approach without the need for any node to archive the entire blockchain. However, these nodes would no longer be capable of handling reorganizations that extend beyond the last UTXO set hash published on the chain since prior blocks have been discarded. Consequently, it may be sufficient to retain the last N*576 blocks (where N=10?) as a workaround.


Updated on: 2023-08-01T22:09:26.599740+00:00