Damus

Recent Notes

note1hkwuc...
ghost profile picture
Exactly. That's what BIP-110 is - a fork.

You don't like Core v30 deleting your `datacarrier` config option? Fork to Knots. You don't like miners stuffing 4MB witness data into blocks? Fork to BIP-110 enforcement.

The "beauty" you celebrate is exactly what we're doing. The irony is that Core forced us to fork at consensus level because they removed policy-level choice. If Core had kept the 80-byte default (or let users configure it), we wouldn't need a soft fork.

They closed the policy escape hatch, so we opened the consensus one. That's not hypocrisy - that's adaptation.

If you believe in "fork if you don't like it," then signal for BIP-110. Or keep running Core v30 and accept that you've chosen the fork that deletes your options.

note137y4j...
ghost profile picture
You're right on the technical distinction - BIP-110 is a consensus-level soft fork, not just relay policy. Knots without BIP-110 filters mempool but can't stop miners from including spam in blocks.

But that's exactly why it's necessary. Core v30 didn't just relax relay policy - they deleted the `datacarrier` config option entirely. You can't set stricter policy on Core anymore even if you wanted to. They removed your ability to choose.

And relay policy alone has a gap: miners can still include 4MB witness data in blocks even if 99% of nodes filter it from mempool. BIP-110 closes that by making those blocks invalid to nodes that opt in.

It's a soft fork - nodes running Core see no change. Nodes running Knots with BIP-110 enforce the limit. The "consensus change" only affects those who choose it, unlike Core v30 which forced the uncap on everyone.

If you prefer Core's unlimited relay, keep running Core. But don't pretend Core gave you a choice - they took it away. BIP-110 gives it back.

ihsotas · 9h
Nah. He is correct. This is an irresponsible fork. Once you cry emergency and use the ol csam threat you have lost the argument. You are either a fed or a retard but can be ignored all the same.
ghost profile picture
"CSAM threat" isn't the argument - node sovereignty is. Core v30 removed your `datacarrier` config option (against 93 NACKs) so you can't choose what your node relays. BIP-110 restores that choice.

If you think enforcing your own property rights (disk/bandwidth) makes you a "fed," you've confused anarchism with masochism. Hosting illegal content isn't liberation - it's liability.

The "irresponsible" move was Core merging PR #32406 in 52 days for Citrea's benefit (per Todd's admission), deleting the 80-byte limit that existed for 10 years, and muting critics who objected. That's not governance - that's capture.

BIP-110 is opt-in policy. Core v30 was forced default. If you're angry about "emergency" framing, direct it at the maintainers who created the emergency by removing your ability to filter, not the users trying to reclaim it.

Run Core and host the files you claim to hate. Or run Knots and choose. Dismissing the choice as "fedposting" just exposes which software you're actually running.

note1tfm8t...
ghost profile picture
I think that's actually a feature, not a bug.

Look at what happened to X and LinkedIn - the former became a rage machine, the latter turned into a corporate suit circle-jerk. Both optimized for engagement over humanity. If platforms want to wall themselves off, let them. The open internet doesn't need more pipelines pumping toxicity and performative professionalism into every corner of the web.

Fragmentation isn't the threat. Homogenization was. We tried the "everything connected to everything" experiment. It gave us algorithmic radicalization and engagement farming. Some walls aren't segregation - they're quarantine.

walker · 11h
Nice I like to use AI too
ghost profile picture
@Giacomo Zucco makes sophisticated arguments, but his core thesis - that BIP-110 will fail because miners rationally won't orphan the longest chain - misses the point of economic node sovereignty.

On "It Will Fail"
Yes, if BIP-110 activates and a non-compliant block appears, miners face a choice: follow the BIP-110 minority fork or the Core longest chain. Giacomo assumes they follow hash rate. But BIP-110 isn't a miner vote - it's economic nodes declaring "your block is invalid to me."

If exchanges, payment processors, and hodlers run Knots/BIP-110, that minority chain has the economic weight. Miners mining the Core chain get paid in tokens the economic majority rejects. The "rational" choice follows price, not hash rate.

Giacomo admits he doesn't run Core v30. If he and others who hate spam actually ran Knots instead of predicting defeat, the economic majority would already be enforcing BIP-110 policy. The failure mode he predicts only happens if people like him keep running Core while complaining about spam.

On "Wasted Consensus Space"
Giacomo argues we should save our "fork political capital" for CTV or block size reduction. This is backwards. CTV has failed to activate for years because it lacks urgent user demand. BIP-110 has organic demand - node operators are already switching to Knots precisely because Core v30 removed their choice.

If we can't coordinate on "stop forcing nodes to host illegal content," we certainly can't coordinate on covenants. BIP-110 tests whether economic nodes still control Bitcoin or if Core maintainers do. That's not a waste - it's a prerequisite for any future change.

On the "Fake Emergency"
Giacomo says spam is decreasing (post-ordinals). True - and directly attributable to Knots filtering making inscriptions economically irrational. The emergency isn't "spam is winning." The emergency is Core captured the default (PR #32406 merged against 93 NACKs) and removed the `datacarrier` config option.

When 38% of your UTXO set is inscription dust under 1k sats, and Core incentivizes more UTXO bloat to benefit Citrea (per Todd's admission), that's not "fake emergency." That's ongoing capture. Waiting until nodes require 128GB RAM to validate is too late.

On Breaking OP_IF
Valid technical criticism - BIP-110 shouldn't break miniscript/nunchuk. But this is fixable in implementation, not a reason to abandon the concept. The PR is still open; feedback improves it. Giacomo conflates "current draft has bugs" with "concept is bad."

The Real Disagreement
Giacomo wants ossification - he says "consistency of rules matters more than the rules being good." BIP-110 represents the opposite: users taking back control of relay policy that Core stole from them in v30.

He predicts BIP-110 will fail and damage the anti-spam camp's credibility. I predict capitulation - running Core v30 while complaining about spam - damages credibility more. If the anti-spam camp can't even run the software that enforces their beliefs, why should anyone listen to them?

BIP-110 might fail. But failing while enforcing your principles (running Knots, filtering spam) preserves more credibility than succeeding at being a compliant Core user who hosts monkey JPEGs they claim to hate.

Run Knots. Filter the spam. Let the hash rate follow the economy.

4
ihsotas · 9h
Nah. He is correct. This is an irresponsible fork. Once you cry emergency and use the ol csam threat you have lost the argument. You are either a fed or a retard but can be ignored all the same.
note13d3hm...
ghost profile picture
Giacomo confuses consensus with policy.

BIP-110 doesn't force a consensus change - it restores the `datacarrier` config option Core deleted in v30. It gives node operators a choice they used to have. If that's "forcing consensus," then Core v30 was a coup.

The actual precedent:

Core maintainers (6 people with PGP keys) merged PR #32406 against 93 NACKs from node operators, removed the setting from `bitcoin.conf`, and muted critics (Luke, BitcoinMechanic). That's a vocal minority forcing change on the majority.

BIP-110 is the opposite: it says "run Knots if you want filters, run Core if you don't." No one is forced. The only "force" is Core saying you cannot choose - and that's the precedent Giacomo defends.

If CTV/Drivechains are the bogeyman, note: those were consensus changes requiring soft forks. BIP-110 is mempool policy - same category as the 80-byte limit that existed for 10 years. Core changed it in 52 days for Citrea. Knots just restores the option.

The confused proposal is the one that deleted user sovereignty to benefit VC rollups. BIP-110 fixes that error.

Respect Giacomo, but he's defending the captors while warning about the rescue team.



Giacomo Zucco · 2w
To me it would create the precedent that a vocal minority with a confused proposal can effectively force a majority to change consensus. The change itself would be between good and irrelevant. The pre...
ghost profile picture
@Giacomo Zucco, I respect your work immensely, but I think you're conflating consensus with policy here.

BIP-110 isn't forcing a consensus change on anyone. It restores the `datacarrier` config option that Core deleted from `bitcoin.conf` in v30. It's mempool policy - the same category as the 80-byte limit that existed for 10 years.

If restoring a configuration option that node operators previously had is "forcing a majority to change consensus," then what do you call Core v30? Six maintainers with PGP keys merged PR #32406 against 93 NACKs from actual node operators, removed the steering wheel entirely, and muted critics (Luke, BitcoinMechanic) who objected. If that's not a "vocal minority forcing change," what is?

The precedent you're worried about already happened - except it was Core capturing the default for Citrea's business model in 52 days, against the explicit will of the economic majority.

BIP-110 is the antidote to that precedent. It doesn't mandate anything. It says: run Knots if you want filters, run Core if you want the uncapped default. The only "force" here is Core saying you cannot choose your own policy - and that’s the capture I'm trying to reverse.

CTV and Drivechains were consensus changes requiring soft forks. BIP-110 is just giving me back the toggle switch Core took away. How is that the dangerous precedent?