Does a trusted blockchain import from BitcoinCore require that chainstate and blocks be from the same source?

Question

Can the chainstate folder from a pruned node be used with the blocks folder from a full node to provide the full blockchain? Assume that both nodes have been running for months.

If the blocks folder contains references to filenames in the chainstate folder, then the answer is no. I know this because the filenames in chainstate on the full node are different from those on the pruned node.

If, on the other hand, the chainstate folder stands as a self-contained and full record of the UTXO Set including all pointers, filenames, and identifiers required to interpret it, then it seems that I will NOT need to import chainstate from the full node to the cloud server.

Bonus question! Out of curiosity, there's another question here that doesn't affect my situation, but it would be nice to understand why the answer is no if it's no. If the chainstate folder on a full node got corrupted, could the chainstate folder from a pruned node be dropped in to recover?

Clarification

Both the blocks and chainstate folders reflect a block tip, and if the two folders reflect different block tips, they will be incompatible. I should have made it explicit that the question assumes that the two different sources of folders would both be synced up to the same block height.

An interesting edge case is what happens if they are using the same block height, but the blocks they used at that height are two valid but different blocks.

Answer 1

I just noticed that the question in the details is the opposite of the question in the title. I am unable to edit the title of this question, so I thought it best to clarify that the question this answer addresses is: "Can the chainstate folder from a pruned node be used with the blocks folder from a full node to provide the full blockchain?"

It appears that the answer is yes. I have not fully established that it was successful, but it looks like it's headed that way. Here are the steps I followed:

1. Shut down the pruned node.
2. Edit bitcoin.conf to change pruned=10000 to pruned=0
3. Update the startup script to point to the new 400GB volume that already has the blocks folder on it.
4. Copy everything except the blocks folder from the current data directory to the new volume.
5. Restart the (now unpruned) node.

Note that none of these steps includes stopping either node at a specific block height. In fact, I'm fairly certain that the problems described below are all a result of the chainstate folder being at a different block height from the blocks folder.

The debug log showed this:

2020-01-02T02:47:48Z : Error initializing block database.
Please restart with -reindex or -reindex-chainstate to recover.
2020-01-02T02:47:48Z Aborted block database rebuild. Exiting.
2020-01-02T02:47:48Z Interrupting HTTP RPC server
2020-01-02T02:47:48Z Interrupting RPC
2020-01-02T02:47:48Z Shutdown: In progress...
2020-01-02T02:47:48Z Stopping HTTP RPC server
2020-01-02T02:47:48Z Stopping RPC
2020-01-02T02:47:48Z RPC stopped.
2020-01-02T02:47:48Z scheduler thread interrupt
2020-01-02T02:47:49Z Shutdown: done

That happened even after I used -reindex-chainstate, so I tried it with -reindex instead, and now it continues to run, reindexing about 460 of the almost 2000 blk#.dat files each hour. If all is well for a while once it's done in about 4 hours, I'll report that here too. Even after it loaded blocks, it had more work to do, although I didn't test to see if it was more functional after the blocks were loaded. It started Updating the tip: 2020-01-04T05:01:06Z UpdateTip: new best=000000000000000000467af08dc436c11dfe1c49d62510aad9753ea3bcd30dc7 height=509848 version=0x20000000 log2_work=88.159019 tx=300224686 date='2018-02-19T00:41:58Z' progress=0.617787 cache=672.1MiB(5030801txo) That seemed to take longer with blocks that had more transactions, suggesting it was still validating (in addition to indexing).

Following is a revised list of steps which could be tested to answer this question with a yes:

1. Copy the blocks folder from the full node to a new data directory for the pruned node, but leave both nodes running.
2. Note the latest file timestamps in the blocks folder of each node.
3. Verify that the block height on each node is the same and then shut them down. Note that if, after shutting down either node, its blocks folder shows a file modification time after those you recorded in the previous step, a block may have been processed on one node and not the other, so start them both up again, don't forget to re-copy the last blk#####.dat file and any rev#####.dat files, and return to the previous step.
4. Edit bitcoin.conf to change pruned=[not 0] to pruned=0
5. Update your .conf file or shortcut to point to the new location for the data directory on the pruned node.
6. Copy everything except the blocks folder from the current data directory on the pruned node to the new one.
7. Restart the (now unpruned) node.

Answer 2

It’s not self contained. The chain state contains references to the positions within the blocks which are unique to the sync state.