Author

Topic: Risks with Assumevalid (Read 111 times)

legendary
Activity: 2856
Merit: 7410
Crypto Swap Exchange
April 21, 2024, 05:36:56 AM
#8
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.
hero member
Activity: 1092
Merit: 520
April 20, 2024, 06:12:55 PM
#7
Thanks for all the replies, particularly from nc50lc.  As always a cool came reply.  Thanks
legendary
Activity: 2856
Merit: 7410
Crypto Swap Exchange
April 18, 2024, 06:47:51 AM
#6
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.
legendary
Activity: 2394
Merit: 5531
Self-proclaimed Genius
April 18, 2024, 05:24:42 AM
#5
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)
legendary
Activity: 1568
Merit: 6660
bitcoincleanup.com / bitmixlist.org
April 18, 2024, 03:58:32 AM
#4
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.
full member
Activity: 266
Merit: 119
Keep Promises !
April 18, 2024, 03:52:39 AM
#3
~
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
legendary
Activity: 3290
Merit: 16489
Thick-Skinned Gang Leader and Golden Feather 2021
April 18, 2024, 03:11:14 AM
#2
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.
hero member
Activity: 1092
Merit: 520
April 17, 2024, 03:31:14 PM
#1
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
Jump to: