"<barlow> believed that anonymity was necessary to freedom. "I feel the same way about anonymity as I do about guns. It may be useful to have in the closet if the government gets out of control."'

deleted by author

original scene with stiffler and ashton kutcher

iiuc

utreexo + swiftsync gets you a genesis validating node in 8 hours with a kilobyte.of storage for bitcoin space.

5x faster than bitcoin core and a billion x less persistent memory.

Hmm, just saw this -- maybe they just cracked doing utreexo with SwiftSync :)

Sorry for using the term "checkpoint" for the assumeValid hash, which clashes with the --checkpoints flag that is no longer used. The hashes used in --assumeValid seem like checkpoints to me, just came out naturally but I am trying to think of a better term. "Trusted States" maybe?

also #1445840

deleted by author

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

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.

Then maybe we should be more careful about language and the terms "full node" and "fully validating node"

evemtually someone will find a way to directly make markets for stocks in bitcoin, rather than pricing everything in usd.

that'll be an interesting day.

Another factor.

I think basel being a bunch of nontechnical old dudes, puts bitcoin and overall crypto in same bucket, probably along with stablecoins and nfts. Honestly I don't blame them, it's treacherous out there.

If so, then until bitcoin gets its own bucket these exageratedly bad nsfrs are probably justified if only to protect banking system from getting looted by crypto rug pulls.

basel 3 nsfr (net stable funding ratio) bitcoin vs gold (google gemini, llmv)

#1409097

Banks will eventually lobby / force basel to make the nsfrs for bitcoin and gold the same. Will take a few years though. Really bitcoin nsfr should be even better than gold due to superior auditability of bitcoin in custody and impossibility to counterfeit bitcoin vs quite possible to bamboozle large quantities of gold if you compromiae the assay team.

Thanks murch, sorry for the confusion Ava.

It seems like there's a bit of a sour dough bread and starter yeast metaphor.

You need some bitcoin node running, that you trust, that you synced from genesis or that someone you trust synced from genesis. That's your starter yeast.

If you have that and want a new node (new loaf of bread), you take a hash of recent block or utxo set commmitment from trusted validated node and sync from there no problem and no need to redo all the work. To make it a bit safer have the block be recent but not too recent, ie sufficiently buried that the amount of work for an attacker to recreate the hashes seems sufficiciently unlikely.

the real issues with assumevalid are
-- A do you trust bitcoin core?
-- B is the checkpoint buried under enpugh work that it feels like you don't even need to trust bitcoin core?
-- if neither A not B by itself is enough to achieve trust, is A + B together enough, and if so why?

Would you agree, or would you say it is more nuanced than that.

fwiw I think both --assumevalid and --assumeutxo reduce bitcoin security.

what I am unclear on is HOW MUCH each one reduces security. just a tiny bit, or enough to matter?