📅 Original date posted:2019-03-10
📝 Original message:What about putting it in a deprecated state for some time. Adjust the
transaction weight so using the op code is more expensive (10x, 20x?) and
get the word out that it will be removed in the future.
You could even have nodes send a reject code with the message
“OP_CODESEPARATOR is depcrecated.”
On Sun, Mar 10, 2019 at 7:55 AM LORD HIS EXCELLENCY JAMES HRMH via
bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> 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 Matt Corallo
> via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
> *Sent:* Saturday, 9 March 2019 7:14 AM
> *To:* Sjors Provoost
> *Cc:* Bitcoin Protocol Discussion
> *Subject:* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great
> Consensus Cleanup
>
> Aside from the complexity issues here, note that for a user to be
> adversely affect, they probably have to have pre-signed lock-timed
> transactions. Otherwise, in the crazy case that such a user exists, they
> should have no problem claiming the funds before activation of a soft-fork
> (and just switching to the swgwit equivalent, or some other equivalent
> scheme). Thus, adding additional restrictions like tx size limits will
> equally break txn.
>
> > On Mar 8, 2019, at 14:12, Sjors Provoost <sjors at sprovoost.nl> wrote:
> >
> >
> >> (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
> _______________________________________________
> 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/a327b977/attachment.html>;
Dustin Dettmer [ARCHIVE] /
npub1x5…kqsqu
2023-06-07 18:16:50
in reply to nevent1q…m98z
Author Public Key
npub1x54n25utwk7dzwzvk2v0aknptez5gxdwcyrxx2wgc0lnhgvwu72qmkqsquPublished at
2023-06-07 18:16:50Event JSON
{
"id": "09f134752cf6bf9772603d8b00d316baaa9c73e0b7b61fad4328ecdfeaf905e2",
"pubkey": "352b35538b75bcd1384cb298feda615e454419aec1066329c8c3ff3ba18ee794",
"created_at": 1686161810,
"kind": 1,
"tags": [
[
"e",
"7188eca60b9414cacad9227d1078e0289be7e78addd56515606897419bb2cf43",
"",
"root"
],
[
"e",
"209890c085ab769213abf4b4af718f8a4b996592cae121fb8d0cf59eb2859807",
"",
"reply"
],
[
"p",
"ccb1b39ff7981d0cca78700c8f4c60435e3789457bf466d14e67125e56a6c5f6"
]
],
"content": "📅 Original date posted:2019-03-10\n📝 Original message:What about putting it in a deprecated state for some time. Adjust the\ntransaction weight so using the op code is more expensive (10x, 20x?) and\nget the word out that it will be removed in the future.\n\nYou could even have nodes send a reject code with the message\n“OP_CODESEPARATOR is depcrecated.”\n\nOn Sun, Mar 10, 2019 at 7:55 AM LORD HIS EXCELLENCY JAMES HRMH via\nbitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e\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 ------------------------------\n\u003e *From:* bitcoin-dev-bounces at lists.linuxfoundation.org \u003c\n\u003e bitcoin-dev-bounces at lists.linuxfoundation.org\u003e on behalf of Matt Corallo\n\u003e via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e *Sent:* Saturday, 9 March 2019 7:14 AM\n\u003e *To:* Sjors Provoost\n\u003e *Cc:* Bitcoin Protocol Discussion\n\u003e *Subject:* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great\n\u003e Consensus Cleanup\n\u003e\n\u003e Aside from the complexity issues here, note that for a user to be\n\u003e adversely affect, they probably have to have pre-signed lock-timed\n\u003e transactions. Otherwise, in the crazy case that such a user exists, they\n\u003e should have no problem claiming the funds before activation of a soft-fork\n\u003e (and just switching to the swgwit equivalent, or some other equivalent\n\u003e scheme). Thus, adding additional restrictions like tx size limits will\n\u003e equally break txn.\n\u003e\n\u003e \u003e On Mar 8, 2019, at 14:12, Sjors Provoost \u003csjors at sprovoost.nl\u003e wrote:\n\u003e \u003e\n\u003e \u003e\n\u003e \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\u003e\n\u003e \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\u003e\n\u003e \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 \u003e\n\u003e \u003e Although I'm not a fan of extra complicity, just to explore these two\n\u003e ideas a bit further.\n\u003e \u003e\n\u003e \u003e What if such a transaction:\n\u003e \u003e\n\u003e \u003e 1. must have one input; and\n\u003e \u003e 2. must be smaller than 400 vbytes; and\n\u003e \u003e 3. must spend from a UTXO older than fork activation\n\u003e \u003e\n\u003e \u003e Adding such a contextual check seems rather painful, perhaps comparable\n\u003e to nLockTime. Anything more specific than the above, e.g. counting the\n\u003e number of OP_CODESEPARATOR calls, seems like guess work.\n\u003e \u003e\n\u003e \u003e Transaction weight currently doesn't consider OP codes, it only\n\u003e considers if bytes are part of the witness. Changing that to something more\n\u003e akin to Ethereums gas pricing sounds too complicated to even consider.\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e I would also like to believe that whoever went through the trouble of\n\u003e using OP_CODESEPARATOR reads this list.\n\u003e \u003e\n\u003e \u003e Sjors\n\u003e \u003e\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 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/a327b977/attachment.html\u003e",
"sig": "d56b496f34772324b59fd9b64078efbf37c1932d296029e8e486cf6f5d8219dd912f7fb3365a28159b6017d1a1f39ed91a2d986f9f3018c7cb532f2812a95947"
}