Murch is right. On the other hand core devs act as they have been compromised.

@Murch post contains a critical oversight in conflating contributors with maintainers (most of the world has the same misconception or wrong perception as well). Bitcoin Core currently has just 5 maintainers with commit access (Hennadii Stepanov, Michael Ford, Andrew Chow, Marco Falke, and Gloria Zhao [just two years ago Gloria told me they were eight contributors then.]), not the "40 regular contributors" mentioned. This distinction matters profoundly for decentralization. The maintainer exodus is concerning - Wladimir van der Laan (lead for 9+ years), Samuel Dobson, and Jonas Schnelli have all departed. These maintainers serve as gatekeepers with actual power to merge code, while contributors merely propose changes. This is a topic rarely discussed because the core of Core is not something you want the world to know about regarding their politics, risks, and threats. That's the main maintenance garage for the only workable money vehicle in human history. Both Core and Knots ultimately represent centralized decision-making structures:Core with its 5-person bottleneck and Knots with its single-developer approach. The recent OP_RETURN controversy perfectly illustrates this tension, with Core's removal of the 80b limit triggering a 137% surge in Knots nodes (from 674 to 1,890 @Luke Dashjr @Bitcoin Mechanic @BTC Sessions ) as users actively choose which monetary values they want preserved. While Bitcoin Core currently benefits from @jack 's principled funding (providing over 60% of its $8.4 million annual development budget), this centralized patronage model fundamentally contradicts Bitcoin's sovereign design and creates vulnerability to future influence shifts. The passionate debates between Bitcoin Core and Knots supporters may appear toxic to outsiders, but these confrontations serve as essential alarm bells that educate the ecosystem about threats to Bitcoin's monetary properties. This is Bitcoin's true governance at work. While development teams may act as centralized decision-makers, ultimate power rests with individual Bitcoiners who collectively determine which vision prevails through their choice of software. Every node operator independently decides which implementation best preserves the monetary properties they value - whether that's #Core 's more permissive approach or #Knots ' stricter filters against non-monetary uses. This symbiotic relationship between Bitcoin and its most principled defenders ensures long-term resilience against changes that might compromise its fundamental value proposition. demonstrating that #Bitcoin needs sound money maximalists, imo, as much as maxis need Bitcoin to preserve the world's only truly sound money.

Never knew about the maintainers!

It also hit me the first time.

🧐

well, don’t you need 51% to change the code ?nodes to agree on it? Also, I think that all the good developers who are working on this nostr platform I believe they have good knowledge. They should move to Bitcoin core core so that monetary system is in the good hands.

The best thing about knots is that it's NOT part of the Bitcoin Core project, at least in terms of governance, while sharing much of the same code, especially consensus related. This is important for people who are unhappy with the direction core is moving and have no other way of expressing themselves besides running a different implementation. Murch raises some concerns about the "unilateral" nature of knots, being modified and maintained, by a single dev (in contrast to core's 40 regular contributors) which makes this PR especially reckless. The person who made the PR (Todd) is telling unhappy node runners to "just run knots" on stage at bitcoin++ while defending on behalf of Core the op_return change he has been a proponent of for some time, and which was met with similar resistance the last time he proposed it. This is in a real sense an endorsement by Core, at least of Knots as a viable alternative. Meanwhile, another core dev Murch, is ringing alarm bells about Knots as a project with "a single developer pushing directly to master without peer review." A project node runners are being told to use by the PR author if they don't like it? Something stinks. This PR should be withdrawn immediately.

Most people think Bitcoin governance is decentralized. It’s not. Here's the uncomfortable truth: You don’t need 51% of miners to change Bitcoin. You just need 5 Core maintainers and a network of node operators who click “update” without reading. That’s not decentralization. That’s blind trust in a gatekeeping elite. Here is how. Bitcoin's 51% hashpower rule protects against double-spends, not protocol changes. Changing the rules requires consensus. but in practice, consensus often follows the code, not the other way around. When Core maintainers approve a change, it propagates silently. Most node operators don’t audit code. They trust. They comply. Exampl: #OPRETURN Core removed the 80-byte limit with almost no discussion. Thousands of nodes implemented it automatically. Most had no idea what changed. That quiet change triggered a silent revolt: #Knots node usage surged 137% as informed operators rejected Core’s move. But let’s be real: That’s a small, technical elite. Most #node runners are flying blind. This creates a hidden centralization vector: #Core devs don’t just write code. they decide which changes even get considered. If they don’t approve it, it doesn’t reach the network. They control what’s ‘acceptable’ and that shapes Bitcoin’s future more than most realize. They decide which changes are “reasonable.” And that shapes Bitcoin’s future. far more than people admit. This isn’t about malice. It’s about structure. Complexity creates dependence. And dependence creates power. #Bitcoin’ s biggest centralization risk isn’t hashpower. It’s the silent authority of trusted code maintainers (of the most dominated node sotwares out there) and the myth that decentralization protects us from that.

I feel like an 18yrs girl driving a Lamborghini (same parallelism with running my node). No idea what happens under the hood.

I respect Murch a lot, but this post only boasts how many people work on core. It doesn’t challenge the idea that the limit should be kept, as espoused by the knots team.

Great analogy

This is why we need to demand more diverse node software, and especially code reviews by various experts in Bitcoin in code, game theory, economics, etc. It's not "trust the experts," it's give me enough information to make an informed choice.

⚡️

"-SIlent authority of trust-" was always the biggest problem of democracy

UK works like that

Maybe the markets pumped Bitcoin as an asset because of the initial commitment to Bitcoin as a decentralised network. If the latter fades, so may the former. Maybe it’s FgU before NgU and not vice versa.

I don’t think the price bumped because people understood bitcoin.

The bitcoin we use today is the result of the open source rough consensus process you say is centralized. We are in fact all talking about a proposed change before it happens and every node operator can then decide whether to update their software or not. Trying to ruin trust in the process and pushing people to software without that same in depth review process might be the real attack vector

Is this "in depth review process" that which led the Core team to even suggest removing the possibility for node runners to decide what they will accept in their own mempool? The same "in depth review process" that dismissed the inscriptions fix as too controversial and rather let the utxo set go to shit?

Yes it is. That is why there has been 100% uptime and no one has had any bitcoin stolen due to bad code. I hate what I think is spam in the database but I hate bugs and insecure software even more. My bitcoin will continue to be protected by a node running bitcoin core software.

i just thought same about update for a sec

I don't understand how allowing limitless OP_RETURN or not filtering inscriptions at mempool level protects theft of funds. If anything, my opinion is that it allows for bitcoin debasement. Nobody I guess uses his bitcoin core as a hot wallet anyway.

If you accept bitcoin for something you gave (dollars, work,product). The only way you can make sure it is real bitcoin is to have your node verify its real which it does by the software it runs. Good luck with your alternate implementation of Bitcoin software 🚁👍🏻

gaslighting much?

Nope. Hoping to keep people from regretting their decision to abandon Core and choose another bitcoin implementation like Knotts. In the end we all choose what software we run and get live with our decision.

Knots has been around for more than 13 years and hundreds of thousands of blocks have been mined with it. I’m pretty confident about it. There’s a non zero chance that there might be some hidden problem with the code but the same thing applies to Core and at this point they’ve lost all credibility.

It will be good if there is a mailing list non-tech node operators can subscribe to, that breaks down latest updates in a way they can understand and decide to upgrade or not.

Remember when the OpenSSL stack in Linux had a backdoor engineered into it for years and years, despite many, many "peer reviews"? This situation with the Bitcoin network is extremely vulnerable, and I would go so far to say that it is already compromised. We just haven't found out yet. Based on the personality types involved with developing and maintaining these systems, it's inevitable that a secret king will pocket a whole lot of money to compromise the system because their feelings got hurt.

nevent1qvzqqqqqqypzqquxdpn0xlh4zqw9k3patfqml9nnndqkyd9e642sfxzlycj5279pqywhwumn8ghj7mn0wd68ytnzd96xxmmfdejhytnnda3kjctv9uq3xamnwvaz7tmsw4e8qmr9wpskwtn9wvhsqgxgsue0wtcm7qmurn5d7efgpjc7ndh70kc9lvzkv94z6wrdd87xtc430fsr

nevent1qqsgesddx3p6llmlvg69wq09wt6c4akvdf3m93v4sakfs26xxg294aspzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhg7hq9d7

What countries control those cores?

Having everyone in the same distro of bitcoin, core in this sense, is the opposite of antifragile.

Definetly not technical elite, those WHO care enough to make a change . Thats who switcher to knotz, not your super technical people, im sure there is some overlap, but i would not consider myself techniccal elite, just cause i can follow straight forward directions.

> Core removed the 80-byte limit with almost no discussion. > Thousands of nodes implemented it automatically. This is complete nonsense. There has not been any removal or change of any limit. There has been ongoing discussion about potentially removing a limit for weeks now. There has not been any new release of Bitcoin Core that implements any change of policy in months. No nodes are implementing anything automatically.

The removal is not yet live on the current mainnet version, but it is finalized and will be the default behavior once the next release is deployed this month on version 30.

Why are you spreading this misinformation? No policy changes have been merged regarding OP_RETURN in Bitcoin Core. Version 30 is not even scheduled for release for another 5 months.

This is straight from the source: Bitcoin Core’s own developers have merged PR #32359 to remove the OP_RETURN limit in the next major release. Check the official GitHub announcement by Greg Sanders on May 5, 2025. >> Repo reference: bitcoin/bitcoin PR #32359 The world’s about to change-don’t blink.

Touché

It’s a software. The maintainers are not the issue. The node runners need to up their sovereignty.

Today you have all the ai tools available for free to translate any code into a narrative a 15yrs old can understand.

There shouldn’t be a trust to rely on. There should be enough curiosity and sovereignty to take the right decision on our own.

Some want bitcoin to just stay sound money. Because this is what they signed up for. And this is exactly what it got bitcoin to what it is today.

You didn't link to the actual PR because it isn't merged. It was closed without merging

GitHub

Build software better, together

GitHub is where people build software. More than 150 million people use GitHub to discover, fork, and contribute to over 420 million projects.

Why are you lying?

You’re right-the PR wasn’t merged, and I appreciate you pointing that out politely. But let’s not miss the forest for the trees. The fact that such a significant change was proposed, debated, and seriously considered by Core devs is the real alarm bell here. For me, what matters isn’t just what gets merged, but what gets momentum. When proposals like this surface, it signals where some want to steer the protocol-often quietly, until it’s too late for pushback. I’m not here to spread FUD or fabricate; I’m here to make sure we stays alert. If we don’t pay attention and speak up, we risk waking up to a very different Bitcoin. Especially that not all mode runners scrutinise every update. That’s not lying-that’s vigilance.

Murch didn't talk about the OP_RETURN limit at all in that post, he was addressing claims that Bitcoin Knots has more developers than Bitcoin Core. If you want to know my thoughts on the policy change, I've left a comment on the PR.

I know your views on that by following your content on Optech.

It might make more sense when you consider that neither Peter nor myself is speaking for Bitcoin Core, but that birth of us are just presenting our own opinions.

No, I did not conflate contributors and maintainers. In Bitcoin Core nothing gets merged until it has been reviewed by several regular contributors, usually several times. Sure, one of the five maintainers (who are part of the regular contributors) is usually the last reviewer and will merge a PR if it has had enough review and they're satisfied, but they don't merge things that haven't been reviewed by other knowledgeable developers, mostly from those 40 regulars.

You're publicly trying to pursuade in favor of a position held by yourselves and other core devs, who collectively have the means and desire to see this change made in the Bitcoin Core software. If you don't want to call that "speaking for Bitcoin Core" then fine, let's have a pointless semantics debate about that.

Appreciate sharing the exact process Murch. What if the maintainer isn’t “satisfied”?

If a pull request doesn't pass review, the reviewers leave feedback on what to improve until it becomes ready for merge or work on it is discontinued. When pull requests run into well-reasoned opposition they tend to get closed to curb review time spent on things that are unlikely to be merged.

New major versions are only released twice a year, in April and October. Even if the PR were merged, which it has not yet, it would not be released until Bitcoin Core 30.0 is released in October.

V30 was clear but didn’t know that the release is in Oct. Thanks for sharing.

And since there has been no merge on PR #32359 how is it likely to play out iyo?

Would you like to share your concrete concerns, so I can address them? I have not received any money or other incentives to have a specific position in this matter, not am I aware of any other participants in this discussion being paid to represent a specific position. To me the arguments for lifting the limit make sense by themselves. My skepticism to the viability of filtering transactions with significant demand aren't exactly new, I pretty much write the same thing on last year's pull request for "match more data carrying" which I found to be similarly poorly motivated.

Hi Murch, thank you for putting out your argument. What I don't understand is why the limit for op_return is being changed when filters are actually working. Yes they don't filter out everything but they do filter out most of it. Then you have a couple of folks claiming that filters are useless and we should give up on them entirely because spammers could use out of bound transactions via services as slipstream by MARA to circumvent filters (which is right but also proves that filters are working pretty well since they wouldn't need to go out of bound otherwise). I may be misrepresenting the opinion by individual core devs since I don't know what everyone said. What puzzles me as well is the statement that transaction fees are enough to filter out spam. You might be right with this claim but I am not sold on it entirely. As long as bitcoin evolves the way as projected and increases in global significance a lot more folks might want to spam the chain even though fees would be higher at that point the incentive for spamming and using more resources to do so would grow similarly. In general I think spam is harmful and might lead to unintended consequences so I don't think we should give non monetary transactions more room and easier ways to use the protocol. I said core seems compromised because they would not ship many "controversial" implementations in the past but this time when controversy is obvious as you can tell from the debate they don't care and ship anyways. My technical skills are limited so I didn't know how to write this up in a shorter manner. I am very interested in your response.

Hey Leon, thanks for your reply. Given the many points you raised, I will quote for context what I’m replying to. > Leon wrote: > What I don't understand is why the limit for op_return is being changed when filters are actually working. Yes they don't filter out everything but they do filter out most of it. I am puzzled how you arrive at the conclusion that they "filter out most of it". 53% of transactions over the past year had OP_RETURN outputs or inscriptions. Could you perhaps explain further what effect you perceive filters to have had? > Leon wrote: > Then you have a couple of folks claiming that filters are useless and we should give up on them entirely because spammers could use out of bound transactions via services as slipstream by MARA to circumvent filters (which is right but also proves that filters are working pretty well since they wouldn't need to go out of bound otherwise). Some miners appear to be running Libre Relay or have otherwise loosened their mempool policy. These miners accept transactions considered non-standard by default Bitcoin Core configurations in-band. They appear to track them normally in their mempools, and include them in their blocks whenever those transaction’s feerates put them in the block. The myth that non-standard transactions need to pay a multiple of other transactions appears to be based on the OP_RETURN_BOT service charging a premium and sending at a higher feerate, but if you are willing to wait, non-standard transactions appear to be getting confirmed at the same feerates as any other txs. > What puzzles me as well is the statement that transaction fees are enough to filter out spam. You might be right with this claim but I am not sold on it entirely. Given limited blockspace, it is obvious that transaction uses that can afford to pay more for blockspace will price out transactions that can only afford to pay little for blockspace. This means especially that large value transfers have a much bigger budget to pay for blockspace than small transfers (if you are sending 10 ₿, you don’t care about paying 10'000 sats in fees, but if you’re trying to send 10'000 sats, paying 10'000 sats is prohibitive). This isn’t a new observation, I wrote in 2016: "Transaction fees are not in relation to the amount of value transferred, but in relation to the amount of block space they'll take. Therefore, it is relatively cheap to send large amounts of value in Bitcoin but uneconomical to send micro-payments." (via

Bitcoin Stack Exchange

Why are transaction fees sometimes higher than what I'm transferring?

Transferring from my wallet to another baffles me prior to the transaction charges. Please someone help. The charges are sometimes higher than what...

I’m not sure what your expectation is, but any form of Bitcoin succeeding will mean that small payments will be economically infeasible on chain. In the past couple years, we saw the third hype wave of people using Bitcoin for publishing data. Just like the prior two times, the excitement eventually subsided and as the premium came down, the cost curbed the transaction volume. Even at the peak of the hype, large transfers easily price out this sort of use. If you are upset that small payments were priced out, I’m afraid that’s the expected outcome either way. I don’t see the point in lying to Bitcoin users by trying to keep transaction fees low artificially. > Leon wrote: > As long as bitcoin evolves the way as projected and increases in global significance a lot more folks might want to spam the chain even though fees would be higher at that point the incentive for spamming and using more resources to do so would grow similarly. > In general I think spam is harmful and might lead to unintended consequences so I don't think we should give non monetary transactions more room and easier ways to use the protocol. OP_RETURN outputs do not grow the UTXO set, because they do not get added to the UTXO set. They are easier to validate than payment outputs, because they don’t contain signature operations. Since OP_RETURN data is in output scripts, it has no witness data that would be discounted. As far as I can tell, besides competing for blockspace, they use less resources in every way than other transactions per byte. Inscriptions also do not increase the UTXO set per se, because it takes creating an output and spending an output to publish the Inscription in the input’s witness stack. Witness data is validated once and retained with a full copy of the blockchain or discarded by pruned nodes as any other blockchain data. It seems to me that most of the UTXO set increase is due to Ordinals—the notion that satoshis have a serial number and some of those serial numbers are more valuable than others—and users splitting up UTXOs to isolate satoshis with certain Ordinals. Sometimes inscriptions are attached to Ordinals, but I’d still blame that on Ordinals more than on Inscriptions. The transactions that split UTXO amounts to isolate certain Ordinals are indistinguishable from payment transactions without out-of-band information about Ordinals, so the main UTXO set bloat is not easy to filter. So, overall I see UTXO bloat from Ordinals and blockspace demand by transactions that offer to pay more for blockspace. I don’t see a practical way of preventing Ordinals, and don’t perceive Inscriptions or OP_RETURN outputs as particularly harmful (dumb sure, but not harmful). Perhaps you could elaborate how spam is harmful, if you disagree, because I don’t see it. > Leon wrote: > I said core seems compromised because they would not ship many "controversial" implementations in the past but this time when controversy is obvious as you can tell from the debate they don't care and ship anyways. I don’t know which examples of controversial changes that did not get shipped you are referring to, but the ones I recall were sunk by convincing technical arguments against them. I have yet to see a convincing technical argument against raising the OP_RETURN limit.

Wow, I am humbled by your response. Thanks for putting all that out. I clearly need to do more research.

Murch, thank you very much for taking your time for such a detailed answer! It is much appreciated.

Thanos for being open to this conversation

the response was perfectly balanced, as all things should be

Ocean had only found 11,895 blocks, and that's if you count the ones found by Eligius.

Actually you’re correct, it turns out I’ve been looking at the “blocks mined” metric. Don’t know why I’ve confused the two and was pretty sure about it on top of that. 🫣