Have @Matthew Kratter , @Luke Dashjr , or @bitcoinmechanic addressed this ? #bitcoin #asknostr
ManyKeys's avatar ManyKeys
The whole BIP-110 brouhaha reads like a self-righteous bureaucrat in a hackerspace: loud, performative, and fundamentally ignorant of the system it claims to “fix.” The recent KnotsLies exposé demolishes core talking points by literally encoding a contiguous image in a transaction that violates none of the rules its proponents say are sacrosanct, exposing that the very limits they want to enforce are either bogus or trivially circumvented — a classic case of ideological zealotry masquerading as technical rigor. Far from protecting #Bitcoin, this faction is pushing arbitrary consensus-level censorship of “non-monetary” data based on subjective judgments about what is “spam,” a slippery slope that corrupts Bitcoin’s neutrality and permissionless ethos. Worse yet, these narratives lean on inflated node counts and hollow signaling to suggest a groundswell that doesn’t exist in economic reality, and they paint market-driven fee dynamics as existential threats while dreaming up governance hooks that invite centralized control. What looks like principled minimalism on the surface is really just a tantrum that weaponizes “technical correctness” to graft political preferences into Bitcoin’s consensus layer, a move as counter to sound money and neutrality as any hard fork ever dreamed of. https://knotslies.com/
View quoted note →

Replies (6)

Read it and you will understand that it is complete and utter Coretard BS. The screenshot is from the link itself: image
BIP 110 allows OP_RETURN up to 82 Bytes for legitimate uses which using that limited space can't abuse Bitcoin. The Coretard (who actually tried to act neutral in the article he wrote 🤡) says basically instead of putting 8 KB spam or 80KB spam in one OP_RETURN he can put it in 100 or in 1000 which will cost him 100x or 1000x more which then will really disincentify spammers. BIP 110 is really good solution to reduce big data spam abuse on Bitcoin. image From the BIP 110 specification: New output scriptPubKeys exceeding 34 bytes are invalid, unless the first opcode is OP_RETURN, in which case up to 83 bytes are valid. OP_PUSHDATA* payloads and script argument witness items exceeding 256 bytes are invalid, except for the redeemScript push in BIP16 scriptSigs. Spending undefined witness (or Tapleaf) versions (ie, not Witness v0/BIP 141, Taproot/BIP 341, or P2A) is invalid. (Creating outputs with undefined witness versions is still valid.) Witness stacks with a Taproot annex are invalid. Taproot control blocks larger than 257 bytes (a merkle tree with 128 script leaves) are invalid. Tapscripts including OP_SUCCESS* opcodes anywhere (even unexecuted) are invalid. Tapscripts executing the OP_IF or OP_NOTIF instruction (regardless of result) are invalid.