pull down to refresh
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.
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
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)
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?
This is all explained better in the utreexo bip
"there are three likely types of nodes:
Compact State Nodes (CSNs)
Bridge nodes
Archive nodes
CSNs have the goal of minimizing data storage and download while performing block validation. Archive and bridge nodes store more data and provide this data to CSNs.
Bridge nodes are nodes that can add inclusion proofs to mempool transactions, support the same set of messages as CSNs, and should in fact be indistinguishable from CSNs on the network. Archive nodes are able to serve the blocks and the inclusion proofs. However, they are not able to generate the inclusion proofs as they do not keep the full UTXO set.
Note that the archive and bridge capabilities of a node are separate; a bridge node can be bridge only, without previous block proof data, and an archive node doesn't need to be able to bridge.
The one exception to this flexibility is that archive nodes must provide both the blocks and the inclusion proofs. While theoretically possible to split these two resources, the blocks are quite small relative to the block proofs, and it simplifies clients to be able to rely on being able to request both over the same connection."
From the docs
https://github.com/utreexo/utreexod
there is option to make bridgenode non archival, so the answer would appear to be no, certainly not EVERY bridgenode needs to be full archival. My poll question could be reformulated, "does any bridgenode need to be full archival?" Intuitively I am with justin_shocknet here and feel that the answer must be yes, and yet the docs are confusing.
A, there is the non archiving bridge node option and
B, (from the link above) " Since miners and nodes publish blocks and transactions without proofs, these nodes are needed to allow for utreexo nodes without a soft fork."
imples that if miners and nodes DID publish blocks and transactions with proofs, there would be no need for bridge nodes. I think probably there is still a need, but a different need than what the documentation is pointing at.
deleted by author