Bitcoin Core developer James O’Beirne has proposed a new way to run a Bitcoin pruned node. His proposal overhauls the conventional method for pruning Bitcoin’s blockchain.
Pruning, of course, has been available to Bitcoin node operators for years.
- A full node is a computer or custom machine that validates proposed Bitcoin transactions against consensus violations like double-spending or increasing the quantity of coins above Bitcoin’s 21 million hard cap. Full nodes validate transactions against Bitcoin’s ruleset plus an unabridged copy of Bitcoin’s ledger of transactions. Bitcoin’s full blockchain is currently over 464GB in size, so most full nodes install a hard drive with storage exceeding 1TB.
- A pruned node drastically reduces the amount of hard drive space required to validate incoming transactions. Pruning eliminates the need to download and store old transactions with a sufficiently high number of confirmations. For instance, a pruned node operator might consider any transactions that have been validated for 100 successive blocks as immutable, allowing their computer to compress all data prior to 100 blocks ago into a single, cryptographic hash.
With standard Bitcoin Core software, node operators enable pruning by setting a maximum number of megabytes they are willing to store in their bitcoin.conf file. They can also modify this setting in the settings area of Bitcoin Core’s graphical user interface (GUI).
The two largest software clients for Bitcoin nodes, Bitcoin Core and Bitcoin QT, can be pruned. However, once the node owner has activated pruning, they may not transmit old blocks over the Bitcoin network nor verify old wallets.
Of course, pruning has trade-offs. First, however, to O’Beirne’s proposal.
James O’Beirne proposes a new way to run a Bitcoin pruned node
O’Beirne has proposed an update to the method by which full nodes prune. This proposal is part of his larger assumeUTXO protocol project.
Rather than the status quo — setting a number of blocks and compressing historical blocks prior to that milestone — O’Beirne’s assumeUTXO is an experimental way for new Bitcoin full nodes to delay their need to verify historical transactions until the user receives recent transactions.
AssumeUTXO-compatible node clients would contain a hard-coded hash of the conditions necessary to spend all bitcoin (the UTXO set) as of a safe, recent point in time (O’Beirne’s variant of the popular Bitcoin Core client, Bitcoin Core #25740, supports assumeUTXO).
Because of its importance, developers would have to check any revision of the hard-coded assumeUTXO hash for correctness during code review. As long as the snapshot hash is correct, it would allow pruned node operators to opt-in to disregarding full data prior to that hash. This trimmed blockchain file would be much smaller than Bitcoin’s entire, half-terabyte blockchain.
In addition, O’Beirne’s proposed update could add background validation to the assumeUTXO protocol. The assumeUTXO proposal adds serialized UTXO sets, reducing the time needed to sync a new Bitcoin node. It also reduces the storage space required to save the Bitcoin blockchain.
Recap of the assumeUTXO pruned node proposal
In summary, James O’Beirne proposes that pruned node operators may optionally trust a developer-reviewed snapshot of the blockchain at a specific point in history. A pruned node can use that snapshot hash to reduce the large file size of Bitcoin’s blockchain.
Once the node has passed an accuracy check of Bitcoin’s ledger using that hash, the node can delete the information used to perform the check the next time the software client restarts. After abridging this data, the node has become a pruned node. Like other pruning techniques, O’Beirne’s proposed feature reduces blockchain storage requirements.
Developers are still working on finalizing the assumeUTXO proposal. To be clear, assumeUTXO is not in consensus with the main Bitcoin network today. Development, safety checks, and code review are ongoing. Bitcoin Core developers are discussing O’Beirne’s proposal, debating its pros and cons, and debugging drafts of code.