Jacob Eliosoff [ARCHIVE] on Nostr: 📅 Original date posted:2019-03-12 📝 Original message:Also, if future disabling ...
📅 Original date posted:2019-03-12
📝 Original message: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 at 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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190312/a6624dfa/attachment.html>;
📝 Original message: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 at 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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190312/a6624dfa/attachment.html>;