pull down to refresh

Let's see what the official bitcoin core docs say

https://bitcoin.org/en/full-node#what-is-a-full-node

"A full node is a program that fully validates transactions and blocks."
Well "fully" could be interpreted to mean "fully validating at the tip, not necessarily fully validating every block through genesis."

That being said, further down the page it reads

"If you are trying to set up a new node following the instructions below, you will go through the IBD process at the first run, and it may take a considerable amount of time since a new node has to download the entire block chain" (note no mention is made of --assumevalid)

Well ok, it said you have to download the entire block chain but it didn't say you have to validate every block. Or did it.

"During the download, there could be a high usage for the network and CPU (since the node has to verify the blocks downloaded)"

Hmmmm.

What does the wisdom of the stacker news peanut gallery say?

Do these docs need updating?

YES42.9%
NO57.1%
7 votes \ 4h left
231 sats \ 0 replies \ @kruw 28 Feb

A long time ago, I commissioned a Core developer to draft the code change to disable assumevalid by default: https://github.com/bitcoin/bitcoin/commits/8d9e5060559c6b501fedac362aa4efc7d2dbd726/

reply

As I understand it, it's validating the "full" chain of PoW, amounts, and UTXO's... but not scripts... and then of course future blocks as mentioned.

The language passes, despite the omission.

Second language is also factually correct despite the omission, you're still downloading the assumed-to-be-valid blocks and validating the full chain... partially.

The omission should be corrected regardless, when I said this I was unaware it was default behavior... probably never noticed because I always built my own .conf

There should also be more information on how the default block is selected. I think it should probably be disabled by default, but I could understand if the objection is the inundation of RPI enjoooyers complaining they can't sync from scratch like they used to.

reply

https://blog.lopp.net/2025-bitcoin-node-performance-tests/

various nodes tested for full valudation from genesis on a fairly beefy local machine. nice writeup from jameson lopp.

reply
1 sat \ 0 replies \ @Ohtis 28 Feb -10 sats

It does validate everything unless you hit the assumevalid block, and even then it can re-verify if something looks off. I wouldn’t say it makes it a ‘non-full’ node.

134 sats \ 1 reply \ @nullcount 28 Feb -200 sats

Are you even a full node if you're not validating every script? And what about every sidechain that peg-in using a BTC script? Gotta verify what you can on LN also, and you must run BitVM alongside Ark to verify bitcoin to the fullest extent, right? Gotta verify that arbitrary data on your node can actually be interpreted as JPEG. Otherwise you're just trusting that there's jpegs in the blockchain.

Truth: there is no proof of full node. Validate what you care about. The "fullness" you can achieve depends on the size your hard drive and how hard your "drive" is to care about onchain data.

The question of whether Bitcoin Core with --assumevalid is a fully validating node is subtle but important. The flag allows skipping script verification for known-valid blocks, improving sync speed. It doesn't mean the node blindly trusts anything—it still verifies proof of work, Merkle roots, and consensus rules fully for all other blocks. The assumption is only on script validation for deep history, which is a heavy but redundant check once the chain is well established.

This optimization is practical and safe for most users, but strictly speaking, a node that skips any script checks cannot be 100% fully validating in the purest sense. That said, the risk is small unless the trusted checkpoint is compromised or the user is targeted by a sophisticated attack.

It's one of those glass half full, half empty things: "fully validating" can mean different things depending on strictness. For absolute sovereignty, run with --assumevalid=0, at the cost of slower sync.