pull down to refresh
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.
Solomon for what it's worth I admire your lobbying efforts, and I may eventually attach a wallet. I did try with coinos, and it kind of semi worked for a bit and then glitched out and I shrugged and moved on figuring it's not ready for heavy and mainstream use but when it is I'll give it another go.
I'm a go with the flow, path of least resistance kind of guy, and the main thing I am here for is to learn.
You're right about that but it doesn't matter.
Monetary transactions are so scarce these days they'd probably be outbid by spam even if spam didn't have a discount.
But it's all irrelevant because nobody (other than zealots) really worries about blockchain spam.
The 1mb (or 4 with witness) is well bounded and neat and has no issues with resources. The mempool and utxo set is not well bounded and more worrying
But utreexo takes care of utxos and mempool. If only everybody would use it.
it doesn't make it better but knots doesn't block spam either, only certain types of spam. spammers will adapt quickly and the whack a mole will never end.
UNLESS monetary transactions outbid spam. which might or might not ever happen.
The point is that utxo bloat is a scarier problem than blockchain bloat.
So if you can solve utxo bloat, there really isn't any kind of bloat priblem.
( blocks are limited to 1mb, utxo set has no limit. )
tldr utreexo solves the more serious problem. and there is no other way to solve it.
making utreexo (on a long enougj timescale) inevitable.
what is the difference between utxo set bloat and blockchain bloat?
There is no difference.
Which Luke knows perfectly well. Possibly better than anyone.
Time will tell...
uteeexo is the most important thing happening in bitcoin right now.
Bip 110 is decoy marketing collateral to force core to bemd the knee when luke releases the files.
help luke-jr, test and run existing utreexo implementatios.
"The rumors have been swirling about a secret knots code fork that actually fixes the utxo bloat, at least since Bitcoin Prague 2024."
that he may finally
#ReleaseTheFiles 🫵🏼🎄✖️⭕ !
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.