👏 👏 👏
Its ok to change your mind.
View quoted note →
Login to reply
Replies (28)
Got making that move today, Scott?!
Don’t go changing your mind to impress me now believing it’s the right move to make, fella.
Now get the fuck out of Europe.
I’ll restrain myself from calling you for what you are, hoping going ok and asking questions like a bitch.
But hey, here is the mathematical conclusion.


Im curious what software you're running on your own node @NVK
Core 19
Would you advise the general pleb to do that also or is that only because you're technically comfortable running older software which likely doesnt include some more/less important security/bug fixes?
For most ppl, I recommend always running Core 2 versions behind.
Sorry, did you mistype 29 or wdym with 2 versions behind? You wrote v19.
I run 19, but for most ppl, i recommend 2 versions behind current. so today that would be 29.
Once core 32 lands, what would be your recommendation to the average pleb?
30
Thanks for your response.
Can I assume that this means you have no objection to the datacarriersize change in v30?
(Or the way it was merged despite controversy)?
If you'd add why you dont object that would be informative.
I think changing the contentious op-return rule was misguided, i don't believe filters work or support any group deciding what goes in or not.
Again, thanks for adding nuance.
I think your own wording is victim of your own bias, respectfully.
"Any group deciding".
Whatever technically goes in AND
Whatever the protocol signals should go in
Is arguably the common directive of bitcoiners as a community, you included.
So if BIP110 is the signal, its also your signal
If 100kb is the signal, its also your signal
I agree completely, no group should decide. But thats the idea behind general consensus, both protocol consensus and social consensus.
You, individually, choose to run core v19, so you are technically signalling some form of opinion.
You also would recommend people run v30 (in due time, when v32 released)
Are you comfortable recommending the average pleb to run software you think includes misguided changes?
Knots is unsafe.
This is a cop-out response, and doesn't answer my question, agree? Btw. I totally get it. Its not an easy debate.
If knots is unsafe, I think bitcoin as a whole would benefit if you would help fix or at least point out any issues you encounter 🙏 maybe you've done that already, I dont know.
By Dewmap
The Capture of Bitcoin Core
For years, Bitcoin maintained a reputation as the ultimate uncapturable network.
It was designed to be decentralized, driven entirely by consensus, and highly resistant to corporate influence.
In 2015, the community famously defended the protocol during the Block Size Wars, repelling a coordinated corporate takeover attempt.
In June 2025, that streak ended.
A heavily contested code change was pushed into the software despite overwhelming opposition from the community.
The update targeted a feature called **OP_RETURN**, a space within a transaction meant to hold tiny amounts of arbitrary data, strictly capped at 80 bytes.
The 2025 update stripped those limits away, allowing massive amounts of non-financial data to be embedded directly into the blockchain.
Bitcoin requires broad consensus to function, and it has no central leadership.
So how did a handful of developers manage to bypass the community and force a major policy change into the software?
---
The path to this change began two years earlier with a six-line administrative edit that went virtually unnoticed.
By early 2023, the small group of developers who maintain Bitcoin's reference software were seeing an influx of traditional venture capital funding.
Major crypto investment firms began directly funding the developers responsible for the software's upkeep.
This financial concentration caught the attention of the mainstream press.
In February 2023, *The Wall Street Journal* profiled the vulnerability, highlighting how few people actually controlled the software and where their funding originated.
Four months later, on June 6, a funded maintainer submitted a code update.
It appeared to be routine housekeeping: a six-line adjustment to the software's documentation strings.
The edit narrowed the written definition of the network's data limits.
The original documentation stated that the limit applied to all data-carrying transactions.
The new text restricted that definition to one specific data field.
This left several newer data pathways completely unregulated, even though the underlying code itself had not changed.
The update passed without scrutiny.
But by quietly altering the official definitions, this developer cohort rewrote the rules of engagement for all future policy debates.
---
In late 2023, new projects began exploiting the exact gaps left open by that documentation edit.
The Bitcoin network was suddenly flooded with digital artifacts and spam, significantly increasing system congestion.
The community attempted to respond.
An independent developer wrote a software patch to restore the original data limits and secured an official security designation from the National Vulnerability Database to track the exploit.
To get that patch implemented, it required approval from the Core maintainers.
They rejected it.
The cohort cited the six-line documentation edit from earlier that year to justify the rejection.
They argued that because the documentation now explicitly excluded those data fields, the spam was technically within the rules.
They claimed that fixing the loophole would violate the software's documented intent.
In October 2024, during a closed-door developer session, the cohort administratively closed the issue tracking the formal security record, effectively erasing the vulnerability designation from the project's history.
By manipulating bureaucratic definitions, a centralized group of developers proved they could protect the specific data streams they favored while blocking community security efforts.
---
By early 2025, a specific corporate interest emerged.
A venture-funded entity called **Citrea** was building a product that required massive, uncapped data limits on Bitcoin to function.
To meet this requirement, an active Core developer commissioned another programmer to submit a code update.
This new pull request proposed removing the OP_RETURN data limit entirely—a change explicitly requested on behalf of Citrea.
When the community discovered the arrangement, they rejected the proposal by roughly a four-to-one margin, citing the clear conflict of interest.
Rather than address the criticism, the developer cohort leveraged their administrative privileges on GitHub to suppress the backlash.
They banned vocal critics, locked discussion threads, and hid comments that pointed out the venture capital ties.
They also utilized a coordinated public relations campaign at the MIT Bitcoin Expo in April 2025.
The cohort's leaders used the university backdrop to project authority, dismissing widespread community opposition as "trolls" and "noise."
The system designed to require broad consensus was being managed to produce the appearance of one.
The decentralized community was systematically silenced by an institutional machine.
---
On June 9, 2025, the uncapped OP_RETURN policy was merged into Bitcoin Core.
Overriding the community's objections, the developers promised a harm-reduction measure.
By opening OP_RETURN, they argued, existing spam would redirect into this cleaner channel, relieving pressure on the network.
But post-merge data showed that the spam did not redirect.
The original channels remained fully active while a new flood emerged through the uncapped space.
The system load compounded.
---
The 2025 merge redefined Bitcoin's governance by demonstrating exactly who holds the levers of power.
This event, according to its critics, showed that Bitcoin Core could be influenced by a centralized group of operators willing to rewrite policy in ways that aligned with particular corporate interests.
Whether one accepts that conclusion or not, the episode has become a case study in the governance of open-source infrastructure and a blueprint—real or perceived—for how a decentralized system can be captured from the inside out.
Source from:
CAPTURE
An investigation into how informal power over Bitcoin Core was assembled, exercised, and defended
by @hodlonaut
Article One of Four — The Network
citadel21.com/the-network
Article Two of Four — The Lever
citadel21.com/the-lever
Article Three of Four — The Merge
citadel21.com/the-merge
View quoted note →
That aged well then..
Lol, what about coldcard?
PSA: Do NOT burn/destroy/reveal/discard your ColdCard seed backup. Long reorgs are a very real threat if the upcoming soft fork has sustained miner collusion against it. This may be part of a state level threat. #Bitcoin #ColdCardExploit #ColdCard
View quoted note →
such weak, feeble dribble...
#retard #slop
You, sir, have earned a spot on my coretards list
Because of the possible split if there is a small number of miners signalling or because there is a technical problem in the code?
No 32 bits is unsafe.
@nvk is reason number 110 why I’m Running rdts
Nvk cannot respond right now because he is bitcoins greatest hypocrite.
What’s this schizo be
😗


Let’s just say, a bet.
@mike
🫶🏻
Why do all the grifters selling defective products all seem to be against bip110?
(Defective product is best case, actual evidence points to this coldcard bug being an intentional exit strategy)