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?
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.
Then maybe we should be more careful about language and the terms "full node" and "fully validating node"
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.
Whatever other noise around this, the term "fully validating node" language does seem to have caused a fair amount of confusion, some of which is reflected in this low sample size poll.
I propose the terms "genesis validating" and "checkpoint validating" to distinguish two scenarios. A "genesis validating" node would be bitcoin core with "--assumeValid=0" ie check everything back to the beginning. Whereas "checkpoint validating" would be the default config scenario which checks some stuff but (waves hands) not other stuff. In theory the other stuff shouldn't matter, because the checkpoint has been buried so deep that hanky panky is unthinkable, but the the fact that SOME validating has been skipped introduces cognitive overhead and doubts.
Further, the whole bitcoin core IBD with default --assumevalid seems to be an kludge. I am sure at the time it was the expedient thing to do.
Now there is a lot of new research that points to better approaches to "genesis validating" without burning out those poor underpowered Rpi devices. Mostly talking about utreexo here, and swiftSync. It seems like we can do a lot better now, eventually, but it's early days and it's going to be a long road.
As side note, interesting comment snip from the SwiftSync announcement, about potential overlaps between SwiftSync and utreexo:
"Note that SwiftSync only concerns itself with IBD, while utreexo also has post-IBD advantages (reducing the state size of the UTXO set). One remaining open question is whether we can end up at the utreexo state and continue from there after using SwiftSync. My intuition is that it should be possible, but this hasn't been confirmed yet."
https://gist.github.com/RubenSomsen/a61a37d14182ccd78760e477c78133cd
Hmm, just saw this -- maybe they just cracked doing utreexo with SwiftSync :)
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/
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.
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.
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.