Not so sure about that.

The client is the protocol. If you want to stay in consensus with the blockchain your only choice for production grade security is to run bitcoin core.

Forks and alternative implementations are a LARP and they always will be until and unless the bitcoin core client runs a library to encapsulate consensus code. This is why I say that libbitcoinkernel is the most important project in bitcoin core. It's the only escape from the Bitcoin Core monopoly.

Consider an example: Google has a monopoly on browser engines even though people "voluntarily choose" to use Chrome. It's a monopoly because the alternatives are fucking garbage and everybody knows it. There is no choice. Only the illusion of choice.

Reply to this note

Please Login to reply.

Discussion

Get out of here with your nuance.

¯\_(ツ)_/¯

No. This misunderstands bitcoin's design because consensus is defined by the network, not the client. Core's code reflects consensus rules but doesn't dictate them.

So to dig a little deeper… What you are saying is that Core’s code reflects consensus rules that the core developers choose but don’t dictate that end users use core?

They don’t dictate, they implement changes aka force without approval.

#mynodemychoice

#bitcoin

#runknots

No. They only have a monopoly on excellence which is why everyone wants to voluntarily run their software. You can't have a monopoly on voluntarism.

A natural monopoly implies network lockin or switching costs and bitcoin has neither, there are no economic, technical, or legal barriers stopping anyone from forking Core, running Knots, or building fresh clients.

Voluntary preference is not market capture, do you understand this yet?

This just sounds desperate.

We are all on the same team. I think Vortex runs knots. He just likes to debate about it.

Yah not even close, I prefer not to lose coin.

Is there a chance that we lose bitcoin with Knots? I prefer not to lose coin also. Sats are limited.

What do you think the % is?

Nearly impossible to calculate exact percentage, the chances of losing coin are simply higher when using non peer reviewed software vs peer reviewed.

The chances are simply higher when using peer-reviewed software vs non peer-reviewed software. They literally can't even hire another dev for Knots despite their best efforts, but nobody wants to work on it 😕

*chances of NOT losing coin are simply higher when using peer-reviewed software

So it is akin to going west until you find land, or Bitcoin in the early days? There are a few pioneers that believed in the project until the project stood on its own? I’m down for that!

I live to be the first or one of the first to something. I like to think that I can see greatness at the beginning along with a few others.

Wish I could’ve found bitcoin earlier though. Ya feel me?

Yah not even close, your analogies seem to keep failing, perhaps because of a lack of technical understanding.

Come on bro. I’m not dissing you. Why do you want to start something here?

You don’t have technical knowledge on women, but you don’t see me on here trying to call you a homo.

Oh wait… let me guess. To have relations with a women I must become a woman?

That is stupid. About as stupid as saying I need technical knowledge on how to code bitcoin or know how it works to hold my own keys.

Let’s assume that everyone needs superior knowledge to hold and use bitcoin. The few developers would be by themselves with a failed project don’t you think? Might as well call it BitDevCoin.

I'm not starting anything, just observing, you simply don't seem technical enough to make relevant analogies (so far in this convo).

Nobody needs technical knowledge to hold bitcoin, but it does help in order to have technical discussions about software development.

Specifically: I am talking about the team they have at Ocean with Datum and Knots. They align with how I feel the world should be.

Can I ask a wild question?

Why don’t Devs want to work with them?

> They align with how I feel the world should be.

Unfortunately "feelings" alone doesn't produce good software.

> Why don’t Devs want to work with them?

That's the question you need to investigate further, from what I can tell no one wants to work with Luke.

Judas betrayed Jesus didn’t he?

Not everyone was built to be great nor understand greatness.

#bitcoin

#knots

#runknots

Virtue signal more why don't you.

I swear that I am soooo close to learning how to code from all of this b.s. going on this round.

I usually don’t allow my emotions to get altered by non sense, but hearing that people don’t want to work with Luke as if he is “bad for bitcoin” is a testament to their short comings. NOT HIS.

> but hearing that people don’t want to work with Luke as if he is “bad for bitcoin” is a testament to their short comings. NOT HIS.

Whatever you gotta tell yourself to sleep at night when using knots.

Please post a rebuttal, all else is a larp.

Tell him again Vortex. He is violating protocol!!!!!

Name one consensus rule that was not first introduced by a code change in bitcoin core.

No, that's a circular argument. Core implements consensus because it reflects what the network enforces. If Core pushed invalid consensus rules the network would fork or reject it. BIP148 (UASF) is a clear example: consensus enforcement came from users, not Core.

No u ♻️

BIP148 is an activation client. There was nothing to activate until core merged the segwit consensus changes. The code change in bitcoin core came first. That's my whole point.

You seem to be arguing from a theoretical perspective. I am arguing from practical reality. There is no trusted bitcoin client except for the original client, bitcoin core. Bitcoin core is a de facto monopoly until and unless they can isolate the consensus code into a library. It doesn't matter what your theory says because this is the reality today and it will stay this way until there is a path for alternative trusted clients to develop.

Core is a monopoly. A central chokepoint. Core developers can wax poetic about how they are a leaderless collective. This is all bullshit. Core, as an institution, is a chokepoint. The failures of this institution extend directly to the bitcoin movement. Bitcoin is at risk of failure as long as this remains the case. Ergo, libbitcoinkernel *should be* the most important priority for long term development.

Bitcoin core is a high status institution and suffers from the inevitable failings of such institutions. It attracts status seeking individuals who act to protect the institution (and their egos) from perceived harm. Like every other high status institution, core has fallen into the trap of tribalism.

The signs are everywhere if you take your blinders off. WTF is "team core"? If you're playing teams you're doing it wrong. I'm not on any team other than team bitcoin. Team freedom.

Codebases mimic their organizational structure. Core is growing super fast and I constantly hear the refrain that they need to grow faster. This is an obvious fallacy! The larger an organization grows the more ineffective it becomes. You can't outgrow your problems if growth itself is the problem.

See the conflict around the *obviously correct* move to split off the GUI and the wallet from the node software. Who would oppose this change? Status seeking individuals who fear losing their status. See the failure to prioritize new opcode development. The entire purpose of bitcoin is to enable permissionless self-custody. When folks try to promote new tools that enable better, easier, safer forms of self custody they get sidelined, ignored, and subjected to straight up obstructionism. See the myopic focus on mempool. See the constant and incorrect assertions on the importance of policy filters for mining pool decentralization. The bitcoin core institution gets so much stuff wrong! It's extremely frustrating to an outside observer.

The institution is showing signs of failure. How long are we going to let this situation persist? Well if history is a guide, it will persist until a crisis arises and the reality distortion field is shattered. Probably in the form of another soft fork war. 👀

I don't have a crystal ball, all I can do is call it like I see it and hope the right folks are listening. Someone's gotta map out the territory ahead and be ready to rebuild when it all goes to shit.

I've said it before and I'll say it again. The best thing core can do for bitcoin is to make themselves redundant.

No actually. You’re describing trust preference not a structural monopoly. Core holds trust because of review depth, audit history, and stability, not enforced control. Anyone can fork or reimplement consensus as BIP148 proved because consensus is what nodes run, not what Core ships. libbitcoinkernel may help modularity, but Core’s influence is earned, not imposed.

I agree, for the most part. We apparently disagree on the practical implications. Or perhaps you are just eliding all pragmatic considerations to continue the debate.

Core has a structural monopoly on consensus code. This is not an attack on core, it is an observation of reality. This is what happens when you yolo a prototype blockchain client into the world. The client is the protocol. Of course this monopoly is not enforced, bitcoin is volunteerism. It doesn't need to be enforced because the disincentive to run any other client is so strong.

Google doesn't 'enforce' their browser monopoly because they don't have to. They can achieve all their monopolistic aims with constant breaking changes. They disincentivize users from running alternative browsers to maintain their monopoly. Same situation as bitcoin, just without an evil corporation pulling the strings.

The disincentive to run nodes with alternative consensus code is a natural outcome of the design of blockchain-based cryptocurrencies. Again, this is not an attack on core, this is an observation of reality. Stop playing teams, bro. It's net negative.

> Core’s influence is earned

A dubious claim since there is no practical alternative. Regardless, they are unearning it, IMO.

Incorrect once again. You’re describing inertia not monopoly. Core’s dominance comes from historical trust and validation not lockin or barriers. The disincentive you mention is risk-aversion not enforced control because any client replicating consensus behavior can replace Core if the network prefers it. That’s not structural monopoly that is voluntary coordination or nakamoto consensus.

Your only counterargument is to make a distinction without a difference.

> any client replicating consensus behavior

That's the rub. No client can guarantee a byte-for-byte replication of bitcoin core behavior. That's the reason core is dominant. That's why we need a consensus library. So all clients can run the exact same code and guarantee the exact same behavior when validating blocks without being forced to run the same p2p code, mempool, policy rules, IBD, template construction, wallet, gui, etc.

Why are you hyper focused on enforcement? Nobody's talking about enforcement but you. Is this like a fetish or something? You're focusing on the wrong thing, bro. It's an utterly irrelevant distinction. It's a straw man.

Anyway, it's been fun. Last reply. Deuces. ✌️

I've already said I agree we need a consensus library and that we need multiple clients, my only argument is that Core is not a monopoly.

Almost as much bullshit as meme reply with zero substance or rebuttal.

No, the consensus at the moment is literally what Core does (which is not all defined), there is more than zero cases of separate implementations having accidental forks because they didn't do exactly what Core does.

The kernel library should fix this, but it is taking very long and won't be ready any time soon.

No. In bitcoin consensus emerges from what nodes choose to run not from what Core ships. The power rests with the network, not the developers.

Except you can't run code unless you are confident it is compatible with what everyone else is running or risk forks which is not acceptable for businesses or most users.

And since there is no spec, no one can run anything that isn't based on Core.

Again, Core is aware of that and that is why the kernel library exists, but it is not ready.

No. You're conflating practical dominance with enforced monopoly. Core is the reference because of trust and audit history not coercion. Nothing stops an alt client from matching consensus behavior (see Knots, Libbitcoin). Core’s dominance remains voluntary not structural or enforced.

Coercion is irrelevant in software anyway, no one is coercing anyone to not fork away at the extreme.

But the lack of neither spec nor extractable kernel, makes running anything but bitcoind not feasible.

Don't take it from me, I already heared at least one core dev describing the kernel library as necessary to reduce the pressure and liability on the Core team.

An ossified kernel, one day, will make Core much less mission critical to Bitcoin, as just another client, probably not even the most popular, while consensus remaining safe.

I am not just saying this to be argumentative, I am deeply in favor of reference implementations vs spec and beps and nips.

But that position HAS to be combined with as simple reference implementation as possible so people can use it while still being able to customise it to serve their needs.

Again, Core itself understand this which is why the kernel is necessary

I agree that libbitcoinkernel will reduce Core’s centrality over time and that an ossified kernel is a good step but claiming non-Core clients are 'not feasible' is wrong. Knots, BTCD, and Libbitcoin exist today and function because feasibility isn't the blocker while trust, audit depth, and adoption are.

But what are people trusting and auditing? It is mainly consensus.

Knots don't count it is just Core with patches, and Libbitcoin is only compatible with Core until it is not. I don't know about BTCD but is that the one where it actually had a fork because it failed to replicate some undocumented Core behaviour? Or was that something else?

At the end of the day, Core is absurdly unwieldy that no one is using it in any mobile device, which is where all payments happen, and they can't optimize for every use case.

I want innovative clients to do their things in different environments, while all knowing that given the same chain of blocks, they will all reach the same conclusion of say UTXO set.

Or at least given the same block they all can be confident they will validate it the same way.

So far the only way to do that was the libbitcoinconsensus which is now deprecated.

You’re right that shared consensus assurance matters but claiming non-Core clients are unfeasible ignores that BTCD, Libbitcoin, and even non-Core forks have validated the chain. BTCD’s historical fork incident proves the point as the network not Core enforced consensus, correcting the client. Core reflects consensus it doesn’t define it. Again I'm all for multiple clients but you cannot define Core as a monopoly.

Not sure what all of that means, but chrome is garbage.