Coming soon: An easier way to bootstrap your node’s UTXO cluster ScrgruppEn

Yesterday we reached the finish line after nearly four years of work. It was Asomiotxo It is integrated into Bitcoin Core master Branch by Andrew Chow yesterday. This is the first major non-consensual update to the Bitcoin reference app in a long time, and it will have a lot of interesting implications for users bootstrapping the nodes.

To give a little context on this feature, I thought it would be helpful to give a little history lesson. When a Bitcoin Core node first boots up and starts synchronizing the blockchain, it doesn’t actually validate the entire historical chain. It is possible, but it does not happen by default, and the reason is to save time and resources on booting. It validates the entire set of blockchain headers to ensure proof-of-work is valid, but it doesn’t actually validate signatures or other witness data for really old blocks. The logic is that for really old blocks, say five years old, it is overkill to actually verify and run signature and other witness checks on those blocks. If someone could mine an invalid block five years ago by spending coins without a valid signature, Bitcoin is essentially broken.

Bitcoin Core has been used to bypass validation of these old blocks using an embedded checkpoint, meaning the developers literally embed the blockchain of a known valid block in the past directly into the validation code and the Core will not check the witness data for anything before that. It was a very innovative solution, and it was not possible for users to change this behavior without modifying the client source code themselves. In 2017 Greg Maxwell provided the supposed job To deal with these issues. Instead of the value included in the source code, it was assumed valid which is a setting that can be modified on startup where users can manually pass the block block themselves and specify which block they will start validating the witness data from. Core still codes the default block for this feature, but the main difference is that users can now easily override this without modifying the source code. Simply run “bitcoind –assumevalid=[theblockhash] Users can decide for themselves what to validate or not. You can run it with assumed=0 to validate every block since Genesis.

Assumeutxo offers very similar functionality for handling UTXO collection. Everything your node does to verify the historical blockchain is done for the sole purpose of building the UTXO pool. You can’t know if a transaction is valid unless you know if the coin has been spent before, and a UTXO set is a cache that a node creates to keep track of all the coins that haven’t been spent. Users have compiled many hacking tools in the past few years to simply skip and start from a good UTXO suite known from some time ago, most of which Especially the BTCPay server. These are all very ugly hacks though and basically boil down to copying and pasting the file directory containing the UTXO array. Now this functionality will be supported in Bitcoin Core.

The implementation by James O’Byrne implemented all the logic for importing and starting a UTXO snapshot, as well as the tools needed to create one in the first place. Just as with assumedvalid, assumeutxo will simply accept an existing snapshot file as an argument, load it into the user node, and start playback from there. This will add a tremendous amount of flexibility to contract operators, both on the end-user side and enterprises.

Users can create a snapshot of their current UTXO collection and store it somewhere; If their node crashes or any of the databases become corrupted, they can simply take a UTXO snapshot and restart their node from the height of the block instead of having to restart from the Genesis block. Users who have trusted relationships with each other can simply help each other start a node from where things are now. No need for further blockchain synchronization at all. If you trust me, I can give you the current UTXO stack of my nodes, and within a few hours of blocks, you can have a node up and running in no time. Businesses that have to run multiple nodes for various reasons can spin them up much faster and easier than UTXO snapshots.

Now, this isn’t quite ready to be rolled out in the next version of Bitcoin Core, however As James said on Twitter The hurdle to cross to get to this point is literally five lines of code. All the core logic and implementation are integrated, and all that needs to be done is to change some flags so that the Core allows users to take advantage of the defaults when running their node on the mainnet.

So, congratulations James on the merger. Many Bitcoin users are looking to have more flexibility and control over their own node.

The most trusted voice in bitcoin, Bitcoin Magazine provides news, analysis, information, commentary, and price data about Bitcoin blockchain tech