Risks with Assumevalid

I am about to do an IBD and i have assumevalid=(Latest block). i understand some of the risks involved with this, regarding being feed a false history etc: But if i don't plan to use the node to validate transactions for a long time 6 month min then i am assuming that my node will eventually check all blocks thoroughly and so its fine.

Thanks

Quote from: calkob on April 17, 2024, 07:31:14 PM

I am about to do an IBD and i have assumevalid=(Latest block). i understand some of the risks involved with this, regarding being feed a false history etc:

How does this work? Will it skip downloading all blocks and only take the latest one? Where are you going to get your chainstate?

Quote

But if i don't plan to use the node to validate transactions for a long time 6 month min then i am assuming that my node will eventually check all blocks thoroughly and so its fine.

Bitcoin Core doesn't check blocks again. It doesn't need to, because it assumes they're valid on disk.

Why not do a normal block download? That's the safest way, and since you have 6 months to do so, the sync time shouldn't be a problem.

Quote from: calkob on April 17, 2024, 07:31:14 PM

You said you could be feed with false history in your post or maybe more that you aren't aware of , then why risk it, just as @LoyceV replied You have 6 months available you could get you bitcoin core sync within weeks or even days so you should just take the normal procedure and not taking shortcut which you might end up blaming yourself

If at any point the UTXO set created in conjunction with hypothetical false blocks conflict with newer transactions included in current mined, authentic blocks, Bitcoin Core is going to complain (loudly) and you're going to have to restart the download again in order to get up-to-date.

In order for you to be fed false blocks in the first place, you would need to be only connected to fake nodes, anyway.

Quote from: calkob on April 17, 2024, 07:31:14 PM

I am about to do an IBD and i have assumevalid=(Latest block). -snip-

assumevalid is activated by default with blockhash of a quite recent block so I don't think setting it up to the tip is even necessary.
In v26.0, it's block height: 804000 (Aug 2023)
In v27.0, it's block height: 824000 (Jan 2024)

If you're using v26.0, you can set it like v.27.0.
But if you really must, leave a week or two weeks worth of script validations, that wont hurt your CPU for long.

Quote from: calkob on April 17, 2024, 07:31:14 PM

i understand some of the risks involved with this, regarding being feed a false history etc

Your node wont have a risk of accepting false history if you ensure that you're connected to a number of peers and not limit it with 1 or a few that could all be rogue nodes.
(hardly even happens with 10)

Your question already answered on https://bitcoin.stackexchange.com/q/88652. In short, assumevalid only skip script verification (usually verify whether the cryptographic signature is valid or not) until certain block passed.

Thanks for all the replies, particularly from nc50lc. As always a cool came reply. Thanks

Quote from: nc50lc on April 18, 2024, 09:24:42 AM

Quote from: calkob on April 17, 2024, 07:31:14 PM

i understand some of the risks involved with this, regarding being feed a false history etc

Forget to say it earlier, but Bitcoin Core also have IP bucketing feature in order to avoid connect node in similar region based on connection type, ASN and IP subnet. It makes connecting only to rogue nodes even more unlikely since attacker need to allocate their rogue nodes on different network.