Why Nostr? What is Njump?
2024-05-02 18:25:56

ROSSTR on Nostr: We need more eyes on the hash based accumulator approach, deployed by Utreexo. ...

We need more eyes on the hash based accumulator approach, deployed by Utreexo.

Perform your initial block download, as normal, and snapshot the UTXO state, at any time, saving it into a QR code or similar.

Bootstrap a new node instnatly, using this QR code, in the event of disaster.

Be an uncle Jim and allow others who trust you to bootstrap their own nodes, in a similar fashion.

As with all scaling there may be tradeoffs. But if it provides a means to stand up a consensus enforcing node in essentially no time, perhaps it's good enough to avoid the race condition that may occur, should a large portion of nodes become unreachable, for whatever reason....
A couple of things here to clarify the importance of full nodes:


First
----------------------------------
The concept and purpose of running a node is very much like the idea that everyone should be able to own a gun to defend liberty.
- It doesn't mean everyone will.
- It doesn't mean individuals can "fight off the government goons" with a handgun.
- It doesn't mean the state isn't more powerful than one person with their gun.
- It DOES mean that to conquer an entire nation of determined, gun owning people who want their liberty requires *active* and *direct* attack, because collectively enough people are armed that popular resistance actually stands a chance against tyrannical governments (who are naturally cowards)

The logic for anyone and everyone running a node who is capable is shockingly similar here.


Second:
----------------------------------
"Have we ever retroactively fixed a 5 year old "error" in the chain? No. Will we ever, no. Do you ever think, I wonder if that transaction from 2016 is still valid, I had better check?"

It isn't really about knowing that every transaction that other people are conducting is valid, it's about ensuring that *the #bitcoin you own* are REAL bitcoin. Bitcoins are created, are defined, and exist entirely and *solely* by a set of rules being followed for how they are created and how they are validly transferred. HALF of the supply of bitcoins was created prior to 2013. If you aren't confirming that the blocks that mined your coins into existence followed the rules, then you don't know if you are following an honest network.
--- The prime example here is Bitcoin Dark, which forked off and created 300K extra coins in the "privacy pool balance," then waited almost a year and a half to withdraw the from the privacy pool and since almost no one ran a full node, it went unnoticed except for a bitcoiner who actually ran full nodes for tons of forks out of curiosity and publicly posted when his node saw the bizarre transaction.
--- You could easily argue that no one needed to care about what happened 15 months ago on the chain... and every one of them was getting scammed specifically because they didn't.

IF we don't have the chain & valid link that traces all the way back to when your coins are created, you have abandoned the triple entry accounting breakthrough.

Third
----------------------------------
It isn't about simply making sure people can keep up with the chain when it comes to cost. It's also about ensuring *real* consensus is maintained (again requiring proof that the bitcoins being transferred are also real) across all borders, against any and all attackers, through any firewalls, on public and private networks, AND can recover after a disaster or massive failure on the network or in the software. Even if cheap SDDs are 50TB, if it takes 6 months to sync the chain, and there is either a direct attack, or a major bug that corrupts the data and forces a reset and sync-from-beginning on 60% of the nodes, that threatens the security and decentralization of the entire global monetary foundation for half a year *at best,* while what may be more likely is that having only 40% of the nodes, just becomes the new normal, and we never go back to the security we once had.

Last
----------------------------------
This is about securing the *trend* of decentralization indefinitely into the future.
It will require constant and deliberate attention and work to ensure it. We will have constant and recurring layers and degrees of centralization in the market, in the technology and hardware around it, in service provision, in some layer on top of Bitcoin that we become overly dependent on, AND on the base layer as costs rise and incentives to run nodes are low. But when an attack arises, when this centralization threatens the censorship resistance, or permission-less nature of the network, we will suddenly and aggressively remember how important it is to run nodes - and it will always be a part of any attempt at defending and repairing those critical re-centralization trends to run a full node, verify everything, and ensure the broadcast layer cannot be squeezed out of existence. That it can be reached to any and all participants no matter where they are in the world.

So the real question is:
Will this get *easier* to secure and protect in 5 years, or will it be *harder*? Because if it is harder, we have a problem, because how much security and decentralization do we lose exactly? 10%? 20%? What happens when we compound that every 5 years for another 50? If we have set it up to become more centralized in an irreparable way, slowly and incrementally, then that's the surest way to guarantee we end up on a system that only a handful of people run and who can dictate or defraud the whole world as to what is a "real" bitcoin and what isn't.


----------------------------------

There are a number of other nuances here because running (and communicating) a full node history isn't merely a problem of hard drive space, in fact, that's the least of the problems and the one that scales the best... while it is still a problem despite. The bigger problems are the computation, the RAM requirements, the speed of data indexing/recall/verification, the bandwidth to download and broadcast the information that is coming to-and-from the base layer, AND of course to then do all of the computation and verification of the *numerous* layers on top of it that we will have to use. Remember that layers themselves are just another trade off, and it's not as if they cost nothing to run. It is merely that they cost *less* to run than scaling on the base layer.

So in short,
you can't really make this short, so read the whole thing.

------------------------------------
Also, I actually kind of like your final argument and position on the "you don't even vote in your own republic" is pretty good, but I think it works *in support* of the full node argument, it doesn't replace it.


Author Public Key
npub1699t5u65fsejvjj5eh6vjd2lj4l8dv0ppssl3dk4ytes33344r4s3vzaf7