đ
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>;
Jacob Eliosoff [ARCHIVE] /
npub1mlâŚ4yf8d
2023-06-07 18:16:48
in reply to nevent1qâŚq4nn
Author Public Key
npub1mlpmsc5sm93tw2fp2dhhuwmxcqm59wz6hjg5g3afq5rucfll3f9sh4yf8dPublished at
2023-06-07 18:16:48Event JSON
{
"id": "8b7eded495db1e5e18ddaa0364aad693e6cf4e9471798e53558edf4c3947fd8c",
"pubkey": "dfc3b86290d962b72921536f7e3b66c03742b85abc914447a90507cc27ff8a4b",
"created_at": 1686161808,
"kind": 1,
"tags": [
[
"e",
"7188eca60b9414cacad9227d1078e0289be7e78addd56515606897419bb2cf43",
"",
"root"
],
[
"e",
"4e06f33ae92acd7b3c5041d574c6f64d8defee8a234ee25a288b5850ba432e1e",
"",
"reply"
],
[
"p",
"cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba"
]
],
"content": "đ
Original date posted:2019-03-12\nđ Original message:Also, if future disabling isn't the point of making a tx type like\nOP_CODESEPARATOR non-standard - what is? If we're committed to indefinite\nsupport of these oddball features, what do we gain by making them hard to\nuse/mine?\n\nI see questions like \"Is it possible someone's existing tx relies on this?\"\nas overly black-and-white. We all agree it's possible: the question is how\nlikely, vs the harms of continued support - including not just security\nrisks but friction on other useful changes, safety/correctness analyses,\netc.\n\nIt is so easy to say stuff like this when one's own money isn't what is at\nrisk.\n\n\nStepping back for a second here: I dispute this framing. My money *is* at\nrisk, because the value of my bitcoins depends on adoption and feature\ngrowth. And I've long viewed an absolutist, actual-known-user-indifferent\napproach to backwards compatibility as the #1 impediment to Bitcoin's\nadoption and growth.\n\nAgain, the point being not to throw caution to the wind, but that a case\nlike this where extensive research unearthed zero users, is taking caution\ntoo far.\n\n\nOn Tue, Mar 12, 2019, 5:48 PM Matt Corallo via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Note that even your carve-outs for OP_NOP is not sufficient here - if you\n\u003e were using nSequence to tag different pre-signed transactions into\n\u003e categories (roughly as you suggest people may want to do with extra sighash\n\u003e bits) then their transactions could very easily have become\n\u003e un-realistically-spendable. The whole point of soft forks is that we\n\u003e invalidate otherwise-unused bits of the protocol. This does not seem\n\u003e inconsistent with the proposal here.\n\u003e\n\u003e \u003e On Mar 9, 2019, at 13:29, Russell O'Connor \u003croconnor at blockstream.io\u003e\n\u003e wrote:\n\u003e \u003e Bitcoin has *never* made a soft-fork, since the time of Satoishi, that\n\u003e invalidated transactions that send secured inputs to secured outputs\n\u003e (excluding uses of OP_NOP1-OP_NOP10).\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190312/a6624dfa/attachment.html\u003e",
"sig": "31f05d4aa5b265c40de794bdb025e5c2edd0b46fd0a2496967d9e2ee97958edeeff59dbd058a73c2c02e3e08f3641b16126c46db048d0466f9915566df19f364"
}