📅 Original date posted:2019-03-10
📝 Original message:I fear that we cannot simply wait 10 years to address the vulnerability
that OP_CODESEPARATOR has in its current form.
On Fri, Mar 8, 2019 at 7:32 PM LORD HIS EXCELLENCY JAMES HRMH <
willtech at live.com.au> wrote:
> Opinion: Lock in a blockheight to get rid of it 10 years in the future.
> Use it as press that Bitcoin is going to lose $1,000,000 if some mystery
> person does not put their transaction through by then, try for global
> presses. Use the opportunity to get rid of it while you are able. Once
> gazetted anything is public knowledge.
>
> Regards,
> LORD HIS EXCELLENCY JAMES HRMH
> ------------------------------
> *From:* bitcoin-dev-bounces at lists.linuxfoundation.org <
> bitcoin-dev-bounces at lists.linuxfoundation.org> on behalf of Sjors
> Provoost via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
> *Sent:* Saturday, 9 March 2019 6:12 AM
> *To:* Matt Corallo; Russell O'Connor; Bitcoin Protocol Discussion
> *Subject:* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great
> Consensus Cleanup
>
>
> > (1) It has been well documented again and again that there is desire to
> remove OP_CODESEPARATOR, (2) it is well-documented OP_CODESEPARATOR in
> non-segwit scripts represents a rather significant vulnerability in Bitcoin
> today, and (3) lots of effort has gone into attempting to find practical
> use-cases for OP_CODESEPARATOR's specific construction, with no successes
> as of yet. I strongly, strongly disagree that the highly-unlikely remote
> possibility that someone created something before which could be rendered
> unspendable is sufficient reason to not fix a vulnerability in Bitcoin
> today.
> >
> >> 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.
>
> Although I'm not a fan of extra complicity, just to explore these two
> ideas a bit further.
>
> What if such a transaction:
>
> 1. must have one input; and
> 2. must be smaller than 400 vbytes; and
> 3. must spend from a UTXO older than fork activation
>
> Adding such a contextual check seems rather painful, perhaps comparable to
> nLockTime. Anything more specific than the above, e.g. counting the number
> of OP_CODESEPARATOR calls, seems like guess work.
>
> Transaction weight currently doesn't consider OP codes, it only considers
> if bytes are part of the witness. Changing that to something more akin to
> Ethereums gas pricing sounds too complicated to even consider.
>
>
> I would also like to believe that whoever went through the trouble of
> using OP_CODESEPARATOR reads this list.
>
> Sjors
>
> _______________________________________________
> 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/20190310/f202bcfa/attachment-0001.html>;
Russell O'Connor [ARCHIVE] /
npub1dw…8plrw
2023-06-07 18:16:52
in reply to nevent1q…ve0n
Author Public Key
npub1dw88wd5gqsqn6ufxhf9h03uk8087l7gfzdtez5csjlt6pupu4pwsj8plrwPublished at
2023-06-07 18:16:52Event JSON
{
"id": "5bb2297e0f3369c164e74126f3c3eb09368d2b25ceeefce5a5ddaf5604f9dd24",
"pubkey": "6b8e77368804013d7126ba4b77c7963bcfeff909135791531097d7a0f03ca85d",
"created_at": 1686161812,
"kind": 1,
"tags": [
[
"e",
"7188eca60b9414cacad9227d1078e0289be7e78addd56515606897419bb2cf43",
"",
"root"
],
[
"e",
"33e48d71b8dbd468e67d4d374e5e1f6cd5612eeb3624b660862d0c1bc154979f",
"",
"reply"
],
[
"p",
"6b8e77368804013d7126ba4b77c7963bcfeff909135791531097d7a0f03ca85d"
]
],
"content": "📅 Original date posted:2019-03-10\n📝 Original message:I fear that we cannot simply wait 10 years to address the vulnerability\nthat OP_CODESEPARATOR has in its current form.\n\nOn Fri, Mar 8, 2019 at 7:32 PM LORD HIS EXCELLENCY JAMES HRMH \u003c\nwilltech at live.com.au\u003e wrote:\n\n\u003e Opinion: Lock in a blockheight to get rid of it 10 years in the future.\n\u003e Use it as press that Bitcoin is going to lose $1,000,000 if some mystery\n\u003e person does not put their transaction through by then, try for global\n\u003e presses. Use the opportunity to get rid of it while you are able. Once\n\u003e gazetted anything is public knowledge.\n\u003e\n\u003e Regards,\n\u003e LORD HIS EXCELLENCY JAMES HRMH\n\u003e ------------------------------\n\u003e *From:* bitcoin-dev-bounces at lists.linuxfoundation.org \u003c\n\u003e bitcoin-dev-bounces at lists.linuxfoundation.org\u003e on behalf of Sjors\n\u003e Provoost via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e *Sent:* Saturday, 9 March 2019 6:12 AM\n\u003e *To:* Matt Corallo; Russell O'Connor; Bitcoin Protocol Discussion\n\u003e *Subject:* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great\n\u003e Consensus Cleanup\n\u003e\n\u003e\n\u003e \u003e (1) It has been well documented again and again that there is desire to\n\u003e remove OP_CODESEPARATOR, (2) it is well-documented OP_CODESEPARATOR in\n\u003e non-segwit scripts represents a rather significant vulnerability in Bitcoin\n\u003e today, and (3) lots of effort has gone into attempting to find practical\n\u003e use-cases for OP_CODESEPARATOR's specific construction, with no successes\n\u003e as of yet. I strongly, strongly disagree that the highly-unlikely remote\n\u003e possibility that someone created something before which could be rendered\n\u003e unspendable is sufficient reason to not fix a vulnerability in Bitcoin\n\u003e today.\n\u003e \u003e\n\u003e \u003e\u003e I suggest an alternative whereby the execution of OP_CODESEPARATOR\n\u003e increases the transactions weight suitably as to temper the vulnerability\n\u003e caused by it. Alternatively there could be some sort of limit (maybe 1) on\n\u003e the maximum number of OP_CODESEPARATORs allowed to be executed per script,\n\u003e but that would require an argument as to why exceeding that limit isn't\n\u003e reasonable.\n\u003e \u003e\n\u003e \u003e You could equally argue, however, that any such limit could render some\n\u003e moderately-large transaction unspendable, so I'm somewhat skeptical of this\n\u003e argument. Note that OP_CODESEPARATOR is non-standard, so getting them mined\n\u003e is rather difficult in any case.\n\u003e\n\u003e Although I'm not a fan of extra complicity, just to explore these two\n\u003e ideas a bit further.\n\u003e\n\u003e What if such a transaction:\n\u003e\n\u003e 1. must have one input; and\n\u003e 2. must be smaller than 400 vbytes; and\n\u003e 3. must spend from a UTXO older than fork activation\n\u003e\n\u003e Adding such a contextual check seems rather painful, perhaps comparable to\n\u003e nLockTime. Anything more specific than the above, e.g. counting the number\n\u003e of OP_CODESEPARATOR calls, seems like guess work.\n\u003e\n\u003e Transaction weight currently doesn't consider OP codes, it only considers\n\u003e if bytes are part of the witness. Changing that to something more akin to\n\u003e Ethereums gas pricing sounds too complicated to even consider.\n\u003e\n\u003e\n\u003e I would also like to believe that whoever went through the trouble of\n\u003e using OP_CODESEPARATOR reads this list.\n\u003e\n\u003e Sjors\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/20190310/f202bcfa/attachment-0001.html\u003e",
"sig": "eb8cf1bf653938172bfdff0656ebb93b5dc6b18c0f90d25f2305bfe4ccf738f89a02356733d5c7a62abacfda95f3826b83a660e87b2adb7ca280a74d8e8d2923"
}