On Thu, Mar 7, 2019 at 2:57 PM Matt Corallo <lf-lists@mattcorallo.com> wrote:

I can't say I'm particularly married to this idea (hence the alternate
proposal in the original email), but at the same time the lack of
existing transactions using these bits (and the redundancy thereof -
they don't *do* anything special) seems to be pretty strong indication
that they are not in use. One could argue a similarity between these
bits and OP_NOPs - no one is going to create transactions that require
OP_NOP execution to be valid as they are precisely the kind of thing
that may get soft-forked to have a new meaning. While the sighash bits
are somewhat less candidates for soft-forking,

I don't think "somewhat less candidates for soft-forking" is a fair description. These bits essentially unsuitable for soft-forking within legacy Script.

I don't think "someone
may have shoved random bits into parts of their
locked-for-more-than-a-year transactions" is sufficient reason to not
soft-fork something out.

I disagree. It is sufficient.

When was the last time Bitcoin soft-forked out working transactions that sent funds from securely held UTXOs to securely held UTXOs (aside from those secured by Scripts using the reserved OP_NOP1-OP_NOP10)? AFAIK it has never occurred since the time of Satoshi, even for the most hypothetical of transactions. It is my understanding is that Bitcoin Core would never do such a thing unless the security of Bitcoin protocol itself was under existential threat (see OP_CODESEPARATOR) and even then Bitcoin Core would only soft-fork out the minimal amount necessary to safely diffuse such a threat.

Since the above soft-fork isn't addressing addressing any such threat (that I'm aware of), and could hypothetically destroy other people money, it crosses a line I thought we were never supposed to cross.

Obviously, actually *seeing* it used in
practice or trying to fork them out in a fast manner would be
unacceptable, but neither is being proposed here.

Perhaps you don't see them in used in the blockchain because the users trying to use them are caught up by the fact they they are not being relayed by default (violating SCRIPT_VERIFY_STRICTENC) and are having difficulty redeeming them.

You cannot first make transactions non-standard and then use the fact that you don't see them being used to justify a soft-fork.

I know of users who have their funds tied up due to other changes in Bitcoin Core's default relay policy. I believe they waiting for their funds to become valuable enough to go through the trouble of having them directly mined. Shall we now permanently destroy their funds too, before they have a chance to get their transactions mined?