📅 Original date posted:2019-03-10
📝 Original message:>
> Instead, it is this soft-fork proposal that is unprecedented. Let me
> reiterate what I posted in another thread:
>
> 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).
>
This principle was only ever a rule of thumb to protect users, not a
commandment from God. It shouldn't be violated lightly, but that's why
Matt did the legwork to show that the tradeoffs around OP_CODESEPARATOR
justify removing it.
Huh?! The whole point of non-standardness in this context is to (a) make
>> soft-forking something out safer by derisking miners not upgrading right
>> away and (b) signal something that may be a candidate for soft-forking
>> out so that we get feedback. Who is getting things disabled who isn't
>> bothering to *tell* people that their use-case is being hurt?!
>>
>
> People have told me that they are hurt by some other non-standardness
> changes and I understand that they have been sitting on those funds for
> years. Maybe they don't realize their is some place to complain or maybe
> they think there must be a good reason why they are not allowed to do what
> they were previously allowed to do. Perhaps others don't want to risk
> blowing their pseudonymity. Perhaps they think that attempting to undo
> some of these non-standardness changes is futile. I can bring up the
> specific cases I've encountered in a new thread if you think it is
> worthwhile.
>
Like Matt, I understand non-standardness to be specifically for making a
transaction type more difficult to set the stage for a future disabling.
If anyone is actually harmed by this change, let them at least speak up
pseudonymously as others have before. Backwards compatibility shouldn't
mean letting imaginary implausible cases veto net-beneficial changes.
On Sat, Mar 9, 2019 at 5:21 PM Russell O'Connor via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi Matt,
>
> On Fri, Mar 8, 2019 at 1:35 PM Matt Corallo <lf-lists at mattcorallo.com>
> wrote:
>
>> Replies inline.
>>
>> On 3/8/19 3:57 PM, Russell O'Connor wrote:
>> > On Thu, Mar 7, 2019 at 2:50 PM Matt Corallo <lf-lists at mattcorallo.com
>> > <mailto:lf-lists at mattcorallo.com>> wrote:
>> > It's very easy to construct a practical script using OP_CODESEPARATOR.
>> >
>> > IF <2> <ALICEPUBKEY> <BOBPUBKEY> <2> CHECKMULTISIGVERIFY ELSE
>> > CODESEPARATOR <ALICEPUBKEY> CHECKSIGVERFY ENDIF
>> >
>> > Now when someone hands Alice, the CFO of XYZ corp., some transaction,
>> > she has the option of either signing it unilaterally herself, or
>> > creating a partial signature such that the transaction additionally
>> > needs Bob, the CEOs signature as well, and Alice's choice is committed
>> > to the blockchain for auditing purposes later.
>> >
>> > Now, there are many things you might object about this scheme, but my
>> > point is that (A) regardless of what you think about this scheme, it,
>> or
>> > similar schemes, may have been devised by users, and (B) users may have
>> > already committed funds to such schemes, and due to P2SH you cannot
>> know
>> > that this is not the case.
>>
>> The common way to set that up is to have a separate key, but, ok, fair
>> enough. That said, the argument that "it may be hidden by P2SH!" isn't
>> sufficient here. It has to *both* be hidden by P2SH and have never been
>> spent from (either on mainnet or testnet) or be lock-timed a year in the
>> future. I'm seriously skeptical that someone is using a highly esoteric
>> scheme and has just been pouring money into it without ever having
>> tested it or having withdrawn any money from it whatsoever. This is just
>> a weird argument.
>>
>
> No one is required to test their Scripts on a public testnet; they can use
> regtest. Because these transactions are non-standard on mainnet, it could
> take years to arrange for these funds to be recovered by having their
> transactions mined directly, or take years to become valuable enough to be
> worth bothering having them directly mined. As I have noted elsewhere, you
> cannot first make transactions non-standard and then use the fact that you
> don't see them being used on mainnet to justify a soft-fork.
>
> My argument isn't weird; it is principled. You are skeptical that any
> uses of OP_CODESEPARATOR have P2SH commitments. I am also skeptical, and
> so is everyone reading this mailing list. But none of us know this with
> certainty, and it is /wrong/ for any of us to gamble with other people's
> money that our assumptions are true.
>
> Instead, it is this soft-fork proposal that is unprecedented. Let me
> reiterate what I posted in another thread:
>
> 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).
>
> The fact that Bitcoin has stuck to this principle gives me and everyone
> else confidence in the protocol; that anyone can secure their funds by
> whatever scheme they dream up, and deploy it without needing permission or
> anyone else to vet their Scripts. So long as they are not impairing the
> Bitcoin protocol itself, the most that Bitcoin Core will do is stop
> relaying their transactions by default.
>
> Undermining this principle means undermining what provides Bitcoin's value
> in the first place.
>
> The problem in this particular case is that there exist valid secure
> transactions that make use OP_CODESEPARATOR such that these transactions
> themselves impair the Bitcoin protocol (through excessive validation costs)
> in a way that, AFAIU, is fundamental to the nature of such transactions (in
> particular, it isn't just due to an implementation detail of Bitcoin
> Core). Thus to fix this vulnerability we must necessarily violate the
> principle of not invalidating, secure transactions. However, this fact
> isn't license to freely invalidate any transactions we want. We ought to
> strive to minimize the scope of violation of this principle. Alice and Bob
> from XYZ. corp should be able to keep their benign transaction illustrated
> above, and we only eliminate those transactions that actually impair the
> Bitcoin protocol.
>
> This is the perfect opportunity to show the world that Bitcoin Core simply
> doesn't take chances when it comes to other people money.
>
> > Please don't strawman my position. I am not suggesting we don't fix a
>> > vulnerability in Bitcoin. I am suggesting we find another way. One
>> > that limits the of risk destroying other people's money.
>> >
>> > Here is a more concrete proposal: No matter how bad OP_CODESEPARATOR
>> > is, it cannot be worse than instead including another input that spends
>> > another identically sized UTXO. So how about we soft-fork in a rule
>> > that says that an input's weight is increased by an amount equal to the
>> > number of OP_CODESEPARATORs executed times the sum of weight of the
>> UTXO
>> > being spent and 40 bytes, the weight of a stripped input. The risk of
>> > destroying other people's money is limited and AFAIU it would
>> completely
>> > address the vulnerabilities caused by OP_CODESEPARATOR.
>>
>> You're already arguing that someone has such an esoteric use of script,
>> suggesting they aren't *also* creating pre-signed, long-locktimed
>> transactions with many inputs isn't much of a further stretch
>> (especially since this may result in the fee being non-standardly low if
>> you artificially increase its weight).
>>
>
> There is no consensus rule about minimum fees, and CPFP could add the more
> fees. But yes, I am saying that Alice and Bob could be building on their
> transaction illustrated above, but not creating a many input tx that
> wouldn't fit into a block with my proposed added weight, because if their
> transaction won't fit into a block with the added weight then it was a
> malicious transaction to begin with.
>
> Do you not recognize the material difference between a soft-fork that
> doubles the cost of a transaction like Alice and Bob's versus making their
> transaction entirely illegal?
>
>
>> Note that "just limit number of OP_CODESEPARATOR calls" results in a ton
>> of complexity and reduces the simple analysis that fees (almost) have
>> today vs just removing it allows us to also remove a ton of code.
>
>
> Further note that if you don't remove it getting the efficiency wins
>> right is even harder because instead of being able to cache sighashes
>> you now have to (at a minimum) wipe the cache between each
>> OP_CODESEPARATOR call, which results in a ton of additional
>> implementation complexity.
>>
>
> How can this be "additional" complexity when this is how the protocol
> works today? All you have to do is not change the semantics of
> OP_CODESEPARATOR. It is literally no work.
> Regarding the efficiency wins, let me repeat myself: The performance costs
> of wiping the cached sighashs is not worse than what the performance costs
> would be if the transaction had an additional input spending an equally
> sized UTXO.
>
>
>> > > I suggest an alternative whereby the execution of
>> OP_CODESEPARATOR
>> > > increases the transactions weight suitably as to temper the
>> > > vulnerability caused by it. Alternatively there could be some
>> > sort of
>> > > limit (maybe 1) on the maximum number of OP_CODESEPARATORs
>> > allowed to be
>> > > executed per script, but that would require an argument as to why
>> > > exceeding that limit isn't reasonable.
>> >
>> > You could equally argue, however, that any such limit could render
>> some
>> > moderately-large transaction unspendable, so I'm somewhat skeptical
>> of
>> > this argument. Note that OP_CODESEPARATOR is non-standard, so
>> getting
>> > them mined is rather difficult in any case.
>> >
>> >
>> > I already know of people who's funds are tied up due to in other
>> changes
>> > to Bitcoin Core's default relay policy. Non-standardness is not an
>> > excuse to take other people's tied up funds and destroy them
>> permanently.
>>
>> Huh?! The whole point of non-standardness in this context is to (a) make
>> soft-forking something out safer by derisking miners not upgrading right
>> away and (b) signal something that may be a candidate for soft-forking
>> out so that we get feedback. Who is getting things disabled who isn't
>> bothering to *tell* people that their use-case is being hurt?!
>>
>
> People have told me that they are hurt by some other non-standardness
> changes and I understand that they have been sitting on those funds for
> years. Maybe they don't realize their is some place to complain or maybe
> they think there must be a good reason why they are not allowed to do what
> they were previously allowed to do. Perhaps others don't want to risk
> blowing their pseudonymity. Perhaps they think that attempting to undo
> some of these non-standardness changes is futile. I can bring up the
> specific cases I've encountered in a new thread if you think it is
> worthwhile.
>
> Regarding OP_CODESEAPRATOR specifically, disabling the rely of such
> transactions partially mitigates the vulnerability. Once the vulnerability
> is properly patched, for example by suitably increasing the weight of the
> operation or opcode, we could drop the prohibition on relaying such
> transactions. Non-standardness is not necessarily a path to a new
> consensus rule. We have several non-standardness rules in place that are
> never intended to become new consensus rules. Sometimes non-standardness
> is a temporary mitigation.
>
> _______________________________________________
> 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/20190309/900b7770/attachment-0001.html>;
Jacob Eliosoff [ARCHIVE] /
npub1ml…4yf8d
2023-06-07 18:16:47
in reply to nevent1q…myz9
Author Public Key
npub1mlpmsc5sm93tw2fp2dhhuwmxcqm59wz6hjg5g3afq5rucfll3f9sh4yf8dPublished at
2023-06-07 18:16:47Event JSON
{
"id": "3c7ff908a81186111ae1476c2aed337dd00561caa227e8873e089e53de742b63",
"pubkey": "dfc3b86290d962b72921536f7e3b66c03742b85abc914447a90507cc27ff8a4b",
"created_at": 1686161807,
"kind": 1,
"tags": [
[
"e",
"7188eca60b9414cacad9227d1078e0289be7e78addd56515606897419bb2cf43",
"",
"root"
],
[
"e",
"56df5233f2774da5c9946ff7de51a360d5939c4e12af3cbd03df04ed6d5e5a56",
"",
"reply"
],
[
"p",
"6b8e77368804013d7126ba4b77c7963bcfeff909135791531097d7a0f03ca85d"
]
],
"content": "📅 Original date posted:2019-03-10\n📝 Original message:\u003e\n\u003e Instead, it is this soft-fork proposal that is unprecedented. Let me\n\u003e reiterate what I posted in another thread:\n\u003e\n\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\nThis principle was only ever a rule of thumb to protect users, not a\ncommandment from God. It shouldn't be violated lightly, but that's why\nMatt did the legwork to show that the tradeoffs around OP_CODESEPARATOR\njustify removing it.\n\nHuh?! The whole point of non-standardness in this context is to (a) make\n\u003e\u003e soft-forking something out safer by derisking miners not upgrading right\n\u003e\u003e away and (b) signal something that may be a candidate for soft-forking\n\u003e\u003e out so that we get feedback. Who is getting things disabled who isn't\n\u003e\u003e bothering to *tell* people that their use-case is being hurt?!\n\u003e\u003e\n\u003e\n\u003e People have told me that they are hurt by some other non-standardness\n\u003e changes and I understand that they have been sitting on those funds for\n\u003e years. Maybe they don't realize their is some place to complain or maybe\n\u003e they think there must be a good reason why they are not allowed to do what\n\u003e they were previously allowed to do. Perhaps others don't want to risk\n\u003e blowing their pseudonymity. Perhaps they think that attempting to undo\n\u003e some of these non-standardness changes is futile. I can bring up the\n\u003e specific cases I've encountered in a new thread if you think it is\n\u003e worthwhile.\n\u003e\n\nLike Matt, I understand non-standardness to be specifically for making a\ntransaction type more difficult to set the stage for a future disabling.\n\nIf anyone is actually harmed by this change, let them at least speak up\npseudonymously as others have before. Backwards compatibility shouldn't\nmean letting imaginary implausible cases veto net-beneficial changes.\n\n\nOn Sat, Mar 9, 2019 at 5:21 PM Russell O'Connor via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Hi Matt,\n\u003e\n\u003e On Fri, Mar 8, 2019 at 1:35 PM Matt Corallo \u003clf-lists at mattcorallo.com\u003e\n\u003e wrote:\n\u003e\n\u003e\u003e Replies inline.\n\u003e\u003e\n\u003e\u003e On 3/8/19 3:57 PM, Russell O'Connor wrote:\n\u003e\u003e \u003e On Thu, Mar 7, 2019 at 2:50 PM Matt Corallo \u003clf-lists at mattcorallo.com\n\u003e\u003e \u003e \u003cmailto:lf-lists at mattcorallo.com\u003e\u003e wrote:\n\u003e\u003e \u003e It's very easy to construct a practical script using OP_CODESEPARATOR.\n\u003e\u003e \u003e\n\u003e\u003e \u003e IF \u003c2\u003e \u003cALICEPUBKEY\u003e \u003cBOBPUBKEY\u003e \u003c2\u003e CHECKMULTISIGVERIFY ELSE\n\u003e\u003e \u003e CODESEPARATOR \u003cALICEPUBKEY\u003e CHECKSIGVERFY ENDIF\n\u003e\u003e \u003e\n\u003e\u003e \u003e Now when someone hands Alice, the CFO of XYZ corp., some transaction,\n\u003e\u003e \u003e she has the option of either signing it unilaterally herself, or\n\u003e\u003e \u003e creating a partial signature such that the transaction additionally\n\u003e\u003e \u003e needs Bob, the CEOs signature as well, and Alice's choice is committed\n\u003e\u003e \u003e to the blockchain for auditing purposes later.\n\u003e\u003e \u003e\n\u003e\u003e \u003e Now, there are many things you might object about this scheme, but my\n\u003e\u003e \u003e point is that (A) regardless of what you think about this scheme, it,\n\u003e\u003e or\n\u003e\u003e \u003e similar schemes, may have been devised by users, and (B) users may have\n\u003e\u003e \u003e already committed funds to such schemes, and due to P2SH you cannot\n\u003e\u003e know\n\u003e\u003e \u003e that this is not the case.\n\u003e\u003e\n\u003e\u003e The common way to set that up is to have a separate key, but, ok, fair\n\u003e\u003e enough. That said, the argument that \"it may be hidden by P2SH!\" isn't\n\u003e\u003e sufficient here. It has to *both* be hidden by P2SH and have never been\n\u003e\u003e spent from (either on mainnet or testnet) or be lock-timed a year in the\n\u003e\u003e future. I'm seriously skeptical that someone is using a highly esoteric\n\u003e\u003e scheme and has just been pouring money into it without ever having\n\u003e\u003e tested it or having withdrawn any money from it whatsoever. This is just\n\u003e\u003e a weird argument.\n\u003e\u003e\n\u003e\n\u003e No one is required to test their Scripts on a public testnet; they can use\n\u003e regtest. Because these transactions are non-standard on mainnet, it could\n\u003e take years to arrange for these funds to be recovered by having their\n\u003e transactions mined directly, or take years to become valuable enough to be\n\u003e worth bothering having them directly mined. As I have noted elsewhere, you\n\u003e cannot first make transactions non-standard and then use the fact that you\n\u003e don't see them being used on mainnet to justify a soft-fork.\n\u003e\n\u003e My argument isn't weird; it is principled. You are skeptical that any\n\u003e uses of OP_CODESEPARATOR have P2SH commitments. I am also skeptical, and\n\u003e so is everyone reading this mailing list. But none of us know this with\n\u003e certainty, and it is /wrong/ for any of us to gamble with other people's\n\u003e money that our assumptions are true.\n\u003e\n\u003e Instead, it is this soft-fork proposal that is unprecedented. Let me\n\u003e reiterate what I posted in another thread:\n\u003e\n\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 The fact that Bitcoin has stuck to this principle gives me and everyone\n\u003e else confidence in the protocol; that anyone can secure their funds by\n\u003e whatever scheme they dream up, and deploy it without needing permission or\n\u003e anyone else to vet their Scripts. So long as they are not impairing the\n\u003e Bitcoin protocol itself, the most that Bitcoin Core will do is stop\n\u003e relaying their transactions by default.\n\u003e\n\u003e Undermining this principle means undermining what provides Bitcoin's value\n\u003e in the first place.\n\u003e\n\u003e The problem in this particular case is that there exist valid secure\n\u003e transactions that make use OP_CODESEPARATOR such that these transactions\n\u003e themselves impair the Bitcoin protocol (through excessive validation costs)\n\u003e in a way that, AFAIU, is fundamental to the nature of such transactions (in\n\u003e particular, it isn't just due to an implementation detail of Bitcoin\n\u003e Core). Thus to fix this vulnerability we must necessarily violate the\n\u003e principle of not invalidating, secure transactions. However, this fact\n\u003e isn't license to freely invalidate any transactions we want. We ought to\n\u003e strive to minimize the scope of violation of this principle. Alice and Bob\n\u003e from XYZ. corp should be able to keep their benign transaction illustrated\n\u003e above, and we only eliminate those transactions that actually impair the\n\u003e Bitcoin protocol.\n\u003e\n\u003e This is the perfect opportunity to show the world that Bitcoin Core simply\n\u003e doesn't take chances when it comes to other people money.\n\u003e\n\u003e \u003e Please don't strawman my position. I am not suggesting we don't fix a\n\u003e\u003e \u003e vulnerability in Bitcoin. I am suggesting we find another way. One\n\u003e\u003e \u003e that limits the of risk destroying other people's money.\n\u003e\u003e \u003e\n\u003e\u003e \u003e Here is a more concrete proposal: No matter how bad OP_CODESEPARATOR\n\u003e\u003e \u003e is, it cannot be worse than instead including another input that spends\n\u003e\u003e \u003e another identically sized UTXO. So how about we soft-fork in a rule\n\u003e\u003e \u003e that says that an input's weight is increased by an amount equal to the\n\u003e\u003e \u003e number of OP_CODESEPARATORs executed times the sum of weight of the\n\u003e\u003e UTXO\n\u003e\u003e \u003e being spent and 40 bytes, the weight of a stripped input. The risk of\n\u003e\u003e \u003e destroying other people's money is limited and AFAIU it would\n\u003e\u003e completely\n\u003e\u003e \u003e address the vulnerabilities caused by OP_CODESEPARATOR.\n\u003e\u003e\n\u003e\u003e You're already arguing that someone has such an esoteric use of script,\n\u003e\u003e suggesting they aren't *also* creating pre-signed, long-locktimed\n\u003e\u003e transactions with many inputs isn't much of a further stretch\n\u003e\u003e (especially since this may result in the fee being non-standardly low if\n\u003e\u003e you artificially increase its weight).\n\u003e\u003e\n\u003e\n\u003e There is no consensus rule about minimum fees, and CPFP could add the more\n\u003e fees. But yes, I am saying that Alice and Bob could be building on their\n\u003e transaction illustrated above, but not creating a many input tx that\n\u003e wouldn't fit into a block with my proposed added weight, because if their\n\u003e transaction won't fit into a block with the added weight then it was a\n\u003e malicious transaction to begin with.\n\u003e\n\u003e Do you not recognize the material difference between a soft-fork that\n\u003e doubles the cost of a transaction like Alice and Bob's versus making their\n\u003e transaction entirely illegal?\n\u003e\n\u003e\n\u003e\u003e Note that \"just limit number of OP_CODESEPARATOR calls\" results in a ton\n\u003e\u003e of complexity and reduces the simple analysis that fees (almost) have\n\u003e\u003e today vs just removing it allows us to also remove a ton of code.\n\u003e\n\u003e\n\u003e Further note that if you don't remove it getting the efficiency wins\n\u003e\u003e right is even harder because instead of being able to cache sighashes\n\u003e\u003e you now have to (at a minimum) wipe the cache between each\n\u003e\u003e OP_CODESEPARATOR call, which results in a ton of additional\n\u003e\u003e implementation complexity.\n\u003e\u003e\n\u003e\n\u003e How can this be \"additional\" complexity when this is how the protocol\n\u003e works today? All you have to do is not change the semantics of\n\u003e OP_CODESEPARATOR. It is literally no work.\n\u003e Regarding the efficiency wins, let me repeat myself: The performance costs\n\u003e of wiping the cached sighashs is not worse than what the performance costs\n\u003e would be if the transaction had an additional input spending an equally\n\u003e sized UTXO.\n\u003e\n\u003e\n\u003e\u003e \u003e \u003e I suggest an alternative whereby the execution of\n\u003e\u003e OP_CODESEPARATOR\n\u003e\u003e \u003e \u003e increases the transactions weight suitably as to temper the\n\u003e\u003e \u003e \u003e vulnerability caused by it. Alternatively there could be some\n\u003e\u003e \u003e sort of\n\u003e\u003e \u003e \u003e limit (maybe 1) on the maximum number of OP_CODESEPARATORs\n\u003e\u003e \u003e allowed to be\n\u003e\u003e \u003e \u003e executed per script, but that would require an argument as to why\n\u003e\u003e \u003e \u003e exceeding that limit isn't reasonable.\n\u003e\u003e \u003e\n\u003e\u003e \u003e You could equally argue, however, that any such limit could render\n\u003e\u003e some\n\u003e\u003e \u003e moderately-large transaction unspendable, so I'm somewhat skeptical\n\u003e\u003e of\n\u003e\u003e \u003e this argument. Note that OP_CODESEPARATOR is non-standard, so\n\u003e\u003e getting\n\u003e\u003e \u003e them mined is rather difficult in any case.\n\u003e\u003e \u003e\n\u003e\u003e \u003e\n\u003e\u003e \u003e I already know of people who's funds are tied up due to in other\n\u003e\u003e changes\n\u003e\u003e \u003e to Bitcoin Core's default relay policy. Non-standardness is not an\n\u003e\u003e \u003e excuse to take other people's tied up funds and destroy them\n\u003e\u003e permanently.\n\u003e\u003e\n\u003e\u003e Huh?! The whole point of non-standardness in this context is to (a) make\n\u003e\u003e soft-forking something out safer by derisking miners not upgrading right\n\u003e\u003e away and (b) signal something that may be a candidate for soft-forking\n\u003e\u003e out so that we get feedback. Who is getting things disabled who isn't\n\u003e\u003e bothering to *tell* people that their use-case is being hurt?!\n\u003e\u003e\n\u003e\n\u003e People have told me that they are hurt by some other non-standardness\n\u003e changes and I understand that they have been sitting on those funds for\n\u003e years. Maybe they don't realize their is some place to complain or maybe\n\u003e they think there must be a good reason why they are not allowed to do what\n\u003e they were previously allowed to do. Perhaps others don't want to risk\n\u003e blowing their pseudonymity. Perhaps they think that attempting to undo\n\u003e some of these non-standardness changes is futile. I can bring up the\n\u003e specific cases I've encountered in a new thread if you think it is\n\u003e worthwhile.\n\u003e\n\u003e Regarding OP_CODESEAPRATOR specifically, disabling the rely of such\n\u003e transactions partially mitigates the vulnerability. Once the vulnerability\n\u003e is properly patched, for example by suitably increasing the weight of the\n\u003e operation or opcode, we could drop the prohibition on relaying such\n\u003e transactions. Non-standardness is not necessarily a path to a new\n\u003e consensus rule. We have several non-standardness rules in place that are\n\u003e never intended to become new consensus rules. Sometimes non-standardness\n\u003e is a temporary mitigation.\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-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190309/900b7770/attachment-0001.html\u003e",
"sig": "15c6ae50464c9ad8ce68a333d3adb040a6e609e568519a7d2725b38e6da8e567d7daaddbdb917a412e4b1305e3dc3840bc6f2718daba88025d9d76c26a64fcfe"
}