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