I simply observed that the query within the particulars is the alternative of the query within the title. I’m unable to edit the title of this query, so I believed it greatest to make clear that the query this reply addresses is: “Can the chainstate folder from a pruned node be used with the blocks folder from a full node to offer the complete blockchain?”
It seems that the reply is sure. I’ve not totally established that it was profitable, but it surely seems to be prefer it’s headed that means. Listed below are the steps I adopted:
- Shut down the pruned node.
- Edit bitcoin.conf to alter pruned=10000 to pruned=0
- Replace the startup script to level to the brand new 400GB quantity that already has the blocks folder on it.
- Copy the whole lot besides the blocks folder from the present knowledge listing to the brand new quantity.
- Restart the (now unpruned) node.
Be aware that none of those steps consists of stopping both node at a particular block peak. In reality, I am pretty sure that the issues described under are all a results of the chainstate folder being at a unique block peak from the blocks folder.
The debug log confirmed this:
2020-01-02T02:47:48Z : Error initializing block database.
Please restart with -reindex or -reindex-chainstate to recuperate.
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: carried out
That occurred even after I used -reindex-chainstate, so I attempted it with -reindex as an alternative, and now it continues to run, reindexing about 460 of the virtually 2000 blk#.dat information every hour. If all is effectively for some time as soon as it is carried out in about 4 hours, I will report that right here too. Even after it loaded blocks, it had extra work to do, though I did not take a look at to see if it was extra useful after the blocks had been loaded. It began Updating the tip:
2020-01-04T05:01:06Z UpdateTip: new greatest=000000000000000000467af08dc436c11dfe1c49d62510aad9753ea3bcd30dc7 peak=509848 model=0x20000000 log2_work=88.159019 tx=300224686 date="2018-02-19T00:41:58Z" progress=0.617787 cache=672.1MiB(5030801txo)
That appeared to take longer with blocks that had extra transactions, suggesting it was nonetheless validating (along with indexing).
Following is a revised checklist of steps which could possibly be examined to reply this query with a sure:
- Copy the blocks folder from the complete node to a brand new knowledge listing for the pruned node, however depart each nodes operating.
- Be aware the most recent file timestamps within the blocks folder of every node.
- Confirm that the block peak on every node is similar after which shut them down. Be aware that if, after shutting down both node, its blocks folder exhibits a file modification time after these you recorded within the earlier step, a block could have been processed on one node and never the opposite, so begin them each up once more, remember to re-copy the final blk#####.dat file and any rev#####.dat information, and return to the earlier step.
- Edit bitcoin.conf to alter pruned=[not 0] to pruned=0
- Replace your .conf file or shortcut to level to the brand new location for the information listing on the pruned node.
- Copy the whole lot besides the blocks folder from the present knowledge listing on the pruned node to the brand new one.
- Restart the (now unpruned) node.