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."
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