How can I rollback Bitcoin Core backwards to re-download some blocks again ?

[scott.carter.2020]

If my Bitcoin Core is fully synced but I want to roll it back to re-download few blocks back, 10 blocks for example, how I can do that safely ?

[1715516911]

1715516911

[1715516911]

1715516911

[1715516911]

1715516911

[1715516911]

1715516911

[LoyceV]

If my Bitcoin Core is fully synced but I want to roll it back to re-download few blocks back, 10 blocks for example, how I can do that safely ?

From what I've read: you should just delete the last few block files in your "blocks" directory. However, when I tried this, it triggered a full download of all blocks.

I'm curious though: why do you want this, if your client is working fine?

[DaveF]

EDIT: The below is bad / wrong advice, but I'm leaving it here as a monument to my stupidity :-)
Seriously, don't do it. ranochigo is correct.
But at least you now know what not to do


You can use the invalidateblock command.

You don't use the block number, you use the block hash.
So from the console if you want to invalidate block 639210 you would use
invalidateblock 0000000000000000000c7072e78db32b61a63fce2e56937167598bbaed9d653d

Then shutdown core and restart and you should pick up from there.

Obligatory, make sure you have a backup of your wallet.dat and anything else you need.

-Dave

[ranochigo]

You can use the invalidateblock command.

You don't use the block number, you use the block hash.
So from the console if you want to invalidate block 639210 you would use
invalidateblock 0000000000000000000c7072e78db32b61a63fce2e56937167598bbaed9d653d

Then shutdown core and restart and you should pick up from there.

Obligatory, make sure you have a backup of your wallet.dat and anything else you need.

-Dave

It won't work. Invalidating the block means that the client marks that block as invalid and the block prior to that will permanently be the longest chain in that client's perspective (unless someone continues to mine from 639209 again onwards). The client will not synchronize anymore after this.

I don't think it deletes the block data either? Just marking it invalid in the chainstate.

[ranochigo]

I don't think it deletes the block data either? Just marking it invalid in the chainstate.

Are you sure? I thought the shutdown / restart would cause it to start up again from where it thought it was.

Let me go spin up a VM and take a look. You could be correct, it's been so long since I used it I don't remember. Only used it a few times for testing.

-Dave

Yep, just tried it again on my testnet. My instance doesn't connect to the peers anymore, probably marked the other nodes as misbehaving nodes. Debug log has this:

Code:

2020-07-14T15:11:09Z ERROR: AcceptBlockHeader: block [Block hash I marked invalid] is marked invalid

.

Anyone knows how to revert this without reindex?

Nevermind, reconsiderblock did the job.

[DaveF]

You are correct, sorry for the bad advice.
-Dave

[OcTradism]

It can only happen with prune node, not full node. Re setup your prune node storage and resync your prune node. It will resync your wallets to latest blocks that fits the new storage parameter you reset.

Of course, problem might be : you must calculate or estimate as exactly as possible the total size of latest blocks you want to redownload.

Cons: you only can do this for latest blocks and can not do it aims at whatever block you want.

I don't do it in practice, it is my shower thought. I thought that total latest blocks with 50 GB for a prune node will be less than total latest blocks with 60 GB for a prune node. (change prune=x)