BitcoinAscent⚡️One Issue Voter⚡️

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.