Also, if future disabling isn't the point of making a tx type like OP_CODESEPARATOR non-standard - what is? If we're committed to indefinite support of these oddball features, what do we gain by making them hard to use/mine?

I see questions like "Is it possible someone's existing tx relies on this?" as overly black-and-white. We all agree it's possible: the question is how likely, vs the harms of continued support - including not just security risks but friction on other useful changes, safety/correctness analyses, etc.

It is so easy to say stuff like this when one's own money isn't what is at risk.

Stepping back for a second here: I dispute this framing. My money is at risk, because the value of my bitcoins depends on adoption and feature growth. And I've long viewed an absolutist, actual-known-user-indifferent approach to backwards compatibility as the #1 impediment to Bitcoin's adoption and growth.

Again, the point being not to throw caution to the wind, but that a case like this where extensive research unearthed zero users, is taking caution too far.

On Tue, Mar 12, 2019, 5:48 PM Matt Corallo via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

Note that even your carve-outs for OP_NOP is not sufficient here - if you were using nSequence to tag different pre-signed transactions into categories (roughly as you suggest people may want to do with extra sighash bits) then their transactions could very easily have become un-realistically-spendable. The whole point of soft forks is that we invalidate otherwise-unused bits of the protocol. This does not seem inconsistent with the proposal here.

> On Mar 9, 2019, at 13:29, Russell O'Connor <roconnor@blockstream.io> wrote:
> Bitcoin has *never* made a soft-fork, since the time of Satoishi, that invalidated transactions that send secured inputs to secured outputs (excluding uses of OP_NOP1-OP_NOP10).

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev