pull down to refresh
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 :)
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.