LORD HIS EXCELLENCY JAMES HRMH [ARCHIVE] on Nostr: 📅 Original date posted:2019-03-12 📝 Original message:I have not seen all of the ...
📅 Original date posted:2019-03-12
📝 Original message:I have not seen all of the emails in reply come through on the mailing list, I am sure it is always that way. There are a couple to reply to, replies indented>:
On Mon, Mar 11, 2019 at 12:47 PM Dustin Dettmer via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org<mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
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.”
>Yes, that sort of thing, widely publicised. Positive publicity is a good thing.
From: Moral Agent via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org<mailto:bitcoin-dev at lists.linuxfoundation.org>>
Sent: Monday, 11 March 2019 5:24 AM
To: LORD HIS EXCELLENCY JAMES HRMH; Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
>Lock in a blockheight to get rid of it 10 years in the future.
And then make UTXOs containing OP_CODESEAPRATOR (etc.) and mined prior to the soft fork activation standard, with weight penalties as appropriate, so there would be no difficulty spending them before the cutoff?
>Yes, precisely that sort of thing so that there is no difficulty spending the UTXOs before the cutoff, preferably we would never prevent spending existing valid transactions in the blockchain, also not only to morally discourage the creation of new transactions with OP_CODESEAPRATOR but to physically prevent them if possible. At the minimum, 10 years of depreciated notifications should be enough for anyone but pre-signed lock-timed transactions may be a different matter. Do we currently allow them to be mined and the UTXO's not valid to be spent until n height/time? We should.
On Sun, Mar 10, 2019 at 10:55 AM LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org<mailto: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<mailto:bitcoin-dev-bounces at lists.linuxfoundation.org> <bitcoin-dev-bounces at lists.linuxfoundation.org<mailto:bitcoin-dev-bounces at lists.linuxfoundation.org>> on behalf of Matt Corallo via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org<mailto: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<mailto: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<mailto:bitcoin-dev at lists.linuxfoundation.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org<mailto: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/f4b775ac/attachment-0001.html>;
📝 Original message:I have not seen all of the emails in reply come through on the mailing list, I am sure it is always that way. There are a couple to reply to, replies indented>:
On Mon, Mar 11, 2019 at 12:47 PM Dustin Dettmer via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org<mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
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.”
>Yes, that sort of thing, widely publicised. Positive publicity is a good thing.
From: Moral Agent via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org<mailto:bitcoin-dev at lists.linuxfoundation.org>>
Sent: Monday, 11 March 2019 5:24 AM
To: LORD HIS EXCELLENCY JAMES HRMH; Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
>Lock in a blockheight to get rid of it 10 years in the future.
And then make UTXOs containing OP_CODESEAPRATOR (etc.) and mined prior to the soft fork activation standard, with weight penalties as appropriate, so there would be no difficulty spending them before the cutoff?
>Yes, precisely that sort of thing so that there is no difficulty spending the UTXOs before the cutoff, preferably we would never prevent spending existing valid transactions in the blockchain, also not only to morally discourage the creation of new transactions with OP_CODESEAPRATOR but to physically prevent them if possible. At the minimum, 10 years of depreciated notifications should be enough for anyone but pre-signed lock-timed transactions may be a different matter. Do we currently allow them to be mined and the UTXO's not valid to be spent until n height/time? We should.
On Sun, Mar 10, 2019 at 10:55 AM LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org<mailto: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<mailto:bitcoin-dev-bounces at lists.linuxfoundation.org> <bitcoin-dev-bounces at lists.linuxfoundation.org<mailto:bitcoin-dev-bounces at lists.linuxfoundation.org>> on behalf of Matt Corallo via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org<mailto: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<mailto: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<mailto:bitcoin-dev at lists.linuxfoundation.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org<mailto: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/f4b775ac/attachment-0001.html>;