Preamble

Bitcoin Core 0.14 introduces assumed-valid blocks, this feature helps increase the speed of the initial blockchain verification process by acknowledging the software that blocks older than the 'hardcoded' one are valid so the sofware can skip checking scripts for its ancestors.

The actual definition can be read here: https://github.com/bitcoin/bitcoin/blob/0.14/doc/release-notes.md#introduction-of-assumed-valid-blocks

With my idea, assumed-valid chain, I propose a method to speed up dramatically the blockchain syncing and signature verification for a newly created prunned node.

How would it work?

The process would be as it follows:

• Bob has already a working and fully-synced Bitcoin Node with prunning disabled
• He already knows what the valid chain is, the list of unspent outputs and so on
• Bob wants to set up a prunned node for himself (or for someone else that trusts Bob)
• Bob tells the software (on the new node) to assume that the chain that he already has is valid.
• Bob provides the new node with X latests blocks and the list of unspent outputs.
• The new node can start in prunned mode just by assuming that the chain Bob provides is valid. (Remember, Bob owns the two nodes).
• The new node just has to verify the latest X blocks (the ones provided by Bob) and download the newer ones (from peers) but never its ancestors.
• From this point, the new node is just another prunned node in the network, it has the same blockchain as a ordinary prunned node.

Pros

• Bob can setup a brand new prunned node in few hours, without downloading the whole chain. This can be useful for low end hardware.

Cons

• Bob needs to know the current state of the chain before setting up the new node.

More explanation

A bitcoin node has to download the chain from the first block because it does not know the current state of the blockchain. This feature is for setting up a second node, it assumes that you already know the state of the chain. This is not initially intended for new users.

When the current Bitcoin Core software is stoped and started it already assuming that the chain that has stored is valid and verified, it just checks latest 100 or so blocks, just to be sure, but it not starts to verify from Genesis Block (because it assumes that blocks in hard-drive were validated when they were downloaded). This also happens when you stop and start a prunned node, without having the old blocks it just assume that they are valid (because they were validated once).

I hope some developer could get interested in my idea and hopefully be discussed.

it's already being worked on in various places, "sync from utxo snapshot" would be a likely query term.

(E.g. https://gist.github.com/n1bor/55b25d72cd3c24eef85f7e24d549ef7a )

There are a number of engineering challenges, like the fact that the UTXO data structure will likely change soon; and how to manage the snapshots without creating sync failures or huge diskspace overhead.

You can do this, sort of:

• On the host you want to sync from, make a copy of the block chain and chainstate. This will take a while and temporarily take up a lot of disk space, however if it works on your system you can avoid that by using this fastcopy_chaindata script, which will hardlink files that can be safely hardlinked (as they don't change) and copy the rest of the files relevant to the chaindata.

• In the copied data directory, enable pruning. Start bitcoind on the copied data directory to make the pruning happen. The result will be a smaller data directory.

• Copy this pruned data directory to your target.

I've used this in practice to bootstrap nodes running on comparatively low-end ARM hardware.

I have found this idea explained by Jonas Schnelli in the Bitcoin-Dev mailing list. https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012478.html

Fast bootstrapping with a pre-generated UTXO-set database

==Abstract== This documents describes a way how bitcoin nodes can bootstrap faster by loading a pre-generated UTXO-set datafile with moderate reduction of the security model.

Let's continue discussion in #15605