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:
- Shut down the pruned node.
- Edit bitcoin.conf to change pruned=10000 to pruned=0
- Update the startup script to point to the new 400GB volume that already has the blocks folder on it.
- Copy everything except the blocks folder from the current data directory to the new volume.
- 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:
- Copy the blocks folder from the full node to a new data directory for the pruned node, but leave both nodes running.
- Note the latest file timestamps in the blocks folder of each node.
- 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.
- Edit bitcoin.conf to change pruned=[not 0] to pruned=0
- Update your .conf file or shortcut to point to the new location for the data directory on the pruned node.
- Copy everything except the blocks folder from the current data directory on the pruned node to the new one.
- Restart the (now unpruned) node.