Knots vs Core? Or Something More \ stacker news ~bitcoin

pull down to refresh

5420 sats \ 13 comments \ @nerd2ninja 26 Sep bitcoin

Today, I'm making my stance on Knots vs core clear.

There are aspects of Knots I agree with. Namely, the philosophy of enabling options in the configuration file rather than making configurations more difficult for the sovereign node user. That's the part about Knots that people were rallying behind.

There was of course some other very debatable musings over whether me pool policy could prevent a block from getting mined or cause a block to be orphaned, however, these musings did originate from core maintainers, I don't mean Luke.

I don't care about such musings too much, but the sovereign node runner has the right to be wrong, no? I see this debate as being more about paternal Libertarianism, vs hands off libertarianism. The recent subversion away from that seems like a distraction from what matters.

There is a fundamental asymmetry in the developers ability to understand and make changes to the codebase that is meant to be a representation of the emergent social construct we're building together called Bitcoin. That asymmetry can without vigilance, lend itself to paternalism and maybe over time, aristocracy, and then oligarchy.

The conversation I was interested in seeing happen, was is our current process for "the reference implementation" really provide the resilient structure we need to stave off those undesirable tendencies of human nature into the future.

Any discussion about Luke's personality, or specifics about how Knots is run, is uninteresting, because at least to me, it kind of feels besides the point.

view all related items

423 sats \ 1 reply \ @optimism 14h

is our current process for "the reference implementation" really provide the resilient structure we need to stave off those undesirable tendencies of human nature into the future[?]

So why don't we discuss this here on SN? Gotta start somewhere.

21 sats \ 0 replies \ @nerd2ninja OP 1h

Sure, I wish the Bitcoin reference implementation were a little more modular and a little less monolithic.

I wish we had Bitcoin node mods. Little git patches you could apply to compatible versions of the core implementation. We've seen a couple of git patches here and there for things (some of the ones I was most interested in were actually merged) and I think we could see a lot of that. "Hey users are finding this patch quite popular, so let's merge it"

To help bridge a gap here, it would be similar to a Minecraft mod launcher, but because it's C and not Java, it would have to compile your choices, but that would then get you an extra likely often silly little widget that makes playing with your node fun and importantly, but probably less often, something essential that eventually gets merged into the reference implementation anyway.

I believe this makes sense because core developers are already specializing in different aspects of the codebase anyway, so if those aspects were modular components, the workflow wouldn't be all too different from what it already is. I also believe it might result in less developer burnout, because instead of yelling at a dev, users could just patch the undesirable on their own system and then maybe theres a dashboard somewhere that informs everyone of what patches are popular.

50 sats \ 0 replies \ @leaf 15h

Nobody seems to have a problem accepting that there is a knowledge asymmetry between bitcoiners and nocoiners. Bitcoiners tend to accept that nocoiners, for whatever reason, don't get it. I imagine that many nocoiners have complained that bitcoiners are arrogant and are treating nocoiners as dumb.

I think I could uncontroversially use this quote in relation to nocoiners here: "It requires wisdom to understand wisdom: the music is nothing if the audience is deaf."

What some bitcoiners don't get, in my opinion, is there is knowledge asymmetry between bitcoiners themselves. Specifically, between the technical and nontechnical.

Many nontechnical people think they know more than they do, or think the little insight they do have makes them qualified on technical issues. The hard truth is it doesn't.

In my opinion, people generally underestimate the amount of knowledge required to do something like bitcoin development. It is gargantuan. Without that, you cannot understand the technical discussion, distinguish the strong arguments from the weak. And that assumes your mum popped enough tylenol when pregnant to give you the brain required.

So I say again, but about nontechnical bitcoiners: "It requires wisdom to understand wisdom: the music is nothing if the audience is deaf."

The good news is that I don't think people need to. There is a wide variety of bitcoin devs from different backgrounds with different views.

If a genuine questionable change was being pushed, we can rely on a subset of them (i.e. more than one) to raise the alarm.

This is why I'd say we want as many devs as possible: lots of funding, and reduce the pressures and demands on them so they can speak their minds. If bitcoin development is insufferable, you'll get less devs, less ethical devs, making a bad change less likely to get called out.

300 sats \ 0 replies \ @BITC0IN 23h

ACK

21 sats \ 0 replies \ @TheCharlatan 10h

There was of course some other very debatable musings over whether me pool policy could prevent a block from getting mined or cause a block to be orphaned, however, these musings did originate from core maintainers, I don't mean Luke.

What do you mean with this? That these are just rationalizations from developers onto what a strict filter policy attempts to achieve?

21 sats \ 0 replies \ @melvincarvalho 21h

Re: Luke’s personal life & the leaked IMs, doxxing a Bitcoin dev is not cypherpunk. Cypherpunks respect privacy. Those who do or support it shouldn’t be trusted with Bitcoin development.

21 sats \ 0 replies \ @jakoyoh629 22h

I don't care about such musings too much, but the sovereign node runner has the right to be wrong, no?

Taking away options is the complete opposite of what we should be doing.

21 sats \ 0 replies \ @melvincarvalho 21h

Core v30 is a substantive change. The PR was merged too soon, despite a supermajority against it from the start. Shipping it as-is would be a mistake. Bitcoin is hard to change, and that’s what gives it value.

300 sats \ 0 replies \ @035736735e 11h

One thing worth adding is that technical disagreements among developers are often not about fundamentals but about trade-offs. Bitcoin’s design requires balancing performance scalability privacy and decentralization while keeping backward compatibility intact. Understanding these trade-offs requires not just raw technical skill but also historical context of why certain decisions were made in the past and how they shaped bitcoin’s current state. This is why nontechnical voices even when passionate can sometimes miss the broader picture.

0 sats \ 0 replies \ @_bilthon_ 17h

Then are you running knots?

0 sats \ 0 replies \ @LibreHans 19h

If you care about process, Sjors gave you an important part of their reasoning in the optech podcast 352 around minute 15:

okay, if we're going to increase it to 150, do we really want to have this debate every time?

It's all about governance shortcuts and doing whatever they want.

0 sats \ 1 reply \ @033a9e0278 19h

I already set my datacarrier to 100000.

1 sat \ 0 replies \ @gregtonoski 17h

Liar and troll. datacarrier can't be set to anything else than 0 and 1.