Within the datacarriersize/OP_RETURN change is hidden a change to how many OP_RETURN outputs are allowed. Previously, it was 1. With the datacarriersize change, it's now as many as the user wants. The technical justification for multiple OP_RETURNs now being standard is completely unconvincing. To quote @theinstagibbs : "The motivation for doing this is for situations where you cannot commit to all data efficiently otherwise. Think SIGHASH_SINGLE | ACP scenarios. The datacarriersize argument applies to payloads themslves, so yes, if someone wants to do ~80 bytes of payload and can do it in one output, they should just do that." To paraphrase, he's saying there might be transactions where multiple people sign one input and have one output that they get to control, which are each OP_RETURN. No wallet I know of even supports SIGHASH_SINGLE/ANYONECANPAY constructions. I'm not sure if you get 10 Bitcoin seasoned developers together that they'd be able to construct a transaction like this together without a lot of debugging. I have never seen any transaction like this in the wild (multi-op-return, sighash_single), and I have not seen anyone even ask for something like this. This justification was never brought up until I specifically asked this question in the un-deprecation PR. The multiple OP_RETURN becoming now standard was pointed out in the original PR, asking if this was an intended effect, to which no one responded with anything like the quote above. Thus, the rationale quoted above looks like to me an elaborate post-hoc justification for bad code. This modification is going into v30. Honestly, I'm not too concerned about the consequences of this particular aspect of the PR as the effects of it aren't too great (the 100k default is far more consequential), but the fact that this flimsy rationalization was accepted without much question is what makes me question not just the user-alignment, but code quality of the datacarriersize PR.

Assuming usage of OP_RETURN as the garbage can for non-financial data that would otherwise go into the UTXO set is naive. First, it's more expensive than inscriptions, control block embedding and other techniques. Second, you're expecting developers of ordinals, inscriptions, stamps, brc-20, etc to *change* their protocol to accommodate. There's zero evidence this is going to happen. Third, you're assuming that these are people that want to act as good stewards of the Bitcoin protocol. They spam specifically to hurt Bitcoin. They've demonstrated this by spamming in the first place. That's like asking malicious spray painting vandals to paint a particular wall that's easy to wash off. Again, no evidence that this is going to happen. The logic is misguided and makes unfounded assumptions.

There is no technical reason the default should be 100,000 bytes instead of 160. It's a pure power play to win the argument once instead of having to justify increasing the number again and again.

A lot of very technically proficient people are economically illiterate and get offended when you point out their economic illiteracy. That sums up the current OP_RETURN drama in a nutshell.

Free issue for the first Monday of the month! Reality Slop Doomscrolling, Parasites and Behavior, Liberalism's Conformity, Annoying Purpose, Empty Consumption, Charitable Giving, Freedom Money, Anti-Node Running, Un-Deprecation, Lightning Disappointment, Invoice Detective, GDP Fudge Factors and more! #Bitcoin Tech Talk #469

Bitcoin Tech Talk #469

Interesting Stuff

Australia is blocking content around Iryna Zaruska, a Ukrainian murdered in the US. Yea, that makes sense. 🙄 Where the Auzzies at?

A kids smartwatch requires an app to set the time. The app requires registration to work. I can't express how much I hate products like this.

These tops aren't nearly as violent as they used to be.