Nostr Web Client

> those ones adopt feature flagging, consensus might change to support

I think you put the cart before the horse. You can't adopt features requiring consensus changes before you get everyone to adopt the consensus change. It doesn't matter how many node implementations there are.

Jack D 1y ago

That's not accurate. Even today many people run nodes supporting different features. Even before the softforks, nodes upgraded to support the features if the softfork might be activated. The problem right now is that Core reviewers are the gatekeepers for consensus implementation.

For a somewhat related example, take Bitcoin Knots. It is essentially a filter that still respects the most proof-of-work chain whatever that might be. The point of it is that if a majority of people adopted it, miners would be forced to update their consensus rules for fear of not having their blocks propagated.

Let's say a worthy alternative implementation gained majority popularity. Would consensus proposal review and reference implementation remain on Core?

Reply to this note

Please Login to reply.

Discussion

vnprc 1y ago

How many consensus changes have you coded up? Are you waiting for bitcoin core reviewers to approve them?

Jack D 1y ago

Are you admitting that Core review is the crux, or are you suggesting my opinion is invalid if I haven't proposed a change to Core?

I heard there was intent to separate consensus rules from Core node implementation, maybe via a library? This would at least be a step in the right direction.

vnprc 1y ago

Just clarifying your level of knowledge of the process. You speak like you have experience. I assume based on your answer that you don't have any first hand knowledge.

I have not proposed a consensus change but I pay close attention to this stuff. Core review is not the blocker. No consensus change has achieved enough momentum to warrant core maintainer code review.

Jack D 1y ago

Maybe you assumed my use of the word "gatekeeper" meant that I was suggesting Core has been actively blocking proposals. As James OB pointed out, there is no direction. Or maybe I've misread or forgotten the point of his article.

vnprc 1y ago

Yeah that's how I read it. Apologies if I misunderstood you.

vnprc 1y ago

Regarding soft forks, the biggest blocker is that the community is fractured. No consensus change will get through until we achieve unity or near unity of opinion on both the necessity and end-goal of a soft fork. I am coming to the opinion that the only way to get there is from a crisis. This is just how anarchy works.

It is unclear to me if we can ever go back to the era of experts pushing through non-essential upgrades. That door may have closed forever. Only time will tell.

So maybe the best thing we can do is keep iterating on proposals that address a specific problem and have them ready to go (or as close as we can manage) in the event that a crisis develops.

I see two developing crises:

- quantum computing

- scaling on-chain throughput

These are not independent concerns. Currently, the best quantum signatures are 100x larger than elliptic curve signatures. So "solving" this crisis will make our scaling problems exponentially worse.

There are a few early stage proposals for quantum resistant signature algorithms but the vast majority of the work remains to be done.

As for scaling, the existing covenant proposals haven't been shown to increase on-chain throughput, which is necessary for self-custody. The layered approach taken by lightning, ecash, ark, et al scales off-chain transaction throughput but at the end of the day users need to withdraw their sats on-chain to cold storage. This will be the bottleneck.

Don't misunderstand me. I'm not saying scaling transaction throughput is not important. If we don't improve bitcoin's usability then we won't have scaling problems because it will stay niche forever.

But when it comes to consensus changes, self-custody is the thing we need to scale. This is how people protect themselves from debasement. If we don't address this problem then what are we even doing here? This was a great point raised by James OB and it has changed my thinking.

I will be applying this new filter when I consider soft fork proposals in the future: does it allow significantly more people to own an on-chain UTXO?

I've made some assumptions in this line of reasoning. It's always good to question your assumptions. There are the open questions in my mind:

Do existing covenants proposals increase on-chain throughput? I wasn't very rigorous in claiming that they don't. It is a loosely held belief.

Can bitcoiners protect themselves from debasement without owning a UTXO? Is a federated model like Liquid or Fedimint good enough? Is a trustless bridge to another chain possible? If it is possible, does it do anything to reduce fees?