Bitcoin Forum

Bitcoin => Bitcoin Technical Support => Topic started by: calkob on April 17, 2024, 07:31:14 PM



Title: Risks with Assumevalid
Post by: 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:  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


Title: Re: Risks with Assumevalid
Post by: LoyceV on April 18, 2024, 07:11:14 AM
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.


Title: Re: Risks with Assumevalid
Post by: promise444c5 on April 18, 2024, 07:52:39 AM
~
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


Title: Re: Risks with Assumevalid
Post by: NotATether on April 18, 2024, 07:58:32 AM
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.


Title: Re: Risks with Assumevalid
Post by: nc50lc on April 18, 2024, 09:24:42 AM
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.

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)


Title: Re: Risks with Assumevalid
Post by: ABCbits on April 18, 2024, 10:47:51 AM
Your question already answered on https://bitcoin.stackexchange.com/q/88652 (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.


Title: Re: Risks with Assumevalid
Post by: calkob on April 20, 2024, 10:12:55 PM
Thanks for all the replies, particularly from nc50lc.  As always a cool came reply.  Thanks


Title: Re: Risks with Assumevalid
Post by: ABCbits on April 21, 2024, 09:36:56 AM
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)

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.