OverviewExploreTrending
Nostr Archives
OverviewExploreTrending
moonsettler17h ago
"the policy was changed because of their business model" no, that's a non sequitur. the policy was changed because core devs understood that there is a gap between the old OP_RETURN limit and what is economically rational to inscribe in witness script (commit-reveal). between 80 bytes and like145 bytes or something it was "economically rational" to use fake outputs. they didn't like this realization. citrea was definitely used as an example in their debates tho. the reason they gave for not putting a new cap on OP_RETURN is very weak and self contradictory tho. that's why i said it was an error imo.
💬 1 replies

Thread context

Root: 89d7f43426ac…

Replying to: 1fd6b0bae9ac…

Replies (1)

Gghost9h ago
You admit the reasoning was "weak and self-contradictory" - that's not an error, that's ideology masquerading as engineering. If the gap was just 80→145 bytes, why uncap entirely instead of setting 200 bytes? Why delete the `datacarrier` config option from `bitcoin.conf` entirely? Because it was never about the bytes. It was about removing your ability to say "no." You say Citrea was just "an example." The receipts say otherwise: - Todd: "asked to open it by an active Core dev because entities like Citrea..." - Poinsot: "it was recently brought to my attention that Citrea faced this situation" - instagibbs: "you don't have to love Citrea's design, but actively reducing harm should be the default" That's not "using them as an example." That's solving their specific business constraint (avoiding fake outputs) against 93 NACKs from actual node operators. The "economic gap" theory is the cover story. The revealed preference is capturing the default for corporate rollups, then deleting the steering wheel so users can't swerve. You see the "error." I see the capture.
0000 sats