> (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@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Reply via email to