rich1.0npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcuhttps://nostr.ae/npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcunjumphttps://nostr.ae📅 Original date posted:2019-03-07 📝 Original message:Replies inline. Matt On 3/7/19 3:03 PM, Russell O'Connor wrote: > > * OP_CODESEPARATOR in non-BIP 143 scripts fails the script validation. > This includes OP_CODESEPARATORs in unexecuted branches of if > statements, > similar to other disabled opcodes, but unlike OP_RETURN. > > > OP_CODESEPARATOR is the only mechanism available that allows users to > sign which particular branch they are authorizing for within scripts > that have multiple possible conditions that reuse the same public key. This is true, and yet it does not appear to actually be practically usable. Thus far, despite a ton of effort, I have not yet seen a practical use-case for OP_CODESEPARATOR (except for one example of it being used to make SegWit scripts ever-so-slightly more effecient in TumbleBit, hence why this BIP does not propose disabling it for SegWit). > Because of P2SH you cannot know that no one is currently using this > feature.  Activating a soft-fork as describe above means these sorts of > funds would be permanently lost.  It is not acceptable to risk people's > money like this. (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.