rich1.0npub1dw88wd5gqsqn6ufxhf9h03uk8087l7gfzdtez5csjlt6pupu4pwsj8plrwhttps://nostr.ae/npub1dw88wd5gqsqn6ufxhf9h03uk8087l7gfzdtez5csjlt6pupu4pwsj8plrwnjumphttps://nostr.ae📅 Original date posted:2019-03-08 📝 Original message:On Thu, Mar 7, 2019 at 2:50 PM Matt Corallo <lf-lists at mattcorallo.com> wrote: > 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). > It's very easy to construct a practical script using OP_CODESEPARATOR. IF <2> <ALICEPUBKEY> <BOBPUBKEY> <2> CHECKMULTISIGVERIFY ELSE CODESEPARATOR <ALICEPUBKEY> CHECKSIGVERFY ENDIF Now when someone hands Alice, the CFO of XYZ corp., some transaction, she has the option of either signing it unilaterally herself, or creating a partial signature such that the transaction additionally needs Bob, the CEOs signature as well, and Alice's choice is committed to the blockchain for auditing purposes later. Now, there are many things you might object about this scheme, but my point is that (A) regardless of what you think about this scheme, it, or similar schemes, may have been devised by users, and (B) users may have already committed funds to such schemes, and due to P2SH you cannot know that this is not the case. > > 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. > Please don't strawman my position. I am not suggesting we don't fix a vulnerability in Bitcoin. I am suggesting we find another way. One that limits the of risk destroying other people's money. Here is a more concrete proposal: No matter how bad OP_CODESEPARATOR is, it cannot be worse than instead including another input that spends another identically sized UTXO. So how about we soft-fork in a rule that says that an input's weight is increased by an amount equal to the number of OP_CODESEPARATORs executed times the sum of weight of the UTXO being spent and 40 bytes, the weight of a stripped input. The risk of destroying other people's money is limited and AFAIU it would completely address the vulnerabilities caused by OP_CODESEPARATOR. Even soft forking a rule like, "it is illegal to execute an OP_CODESEPARATOR after any CHECKSIG/CHECKMULTISIG operation", would be vastly better than the current proposal, even though I would still object to it. > > 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. > I already know of people who's funds are tied up due to in other changes to Bitcoin Core's default relay policy. Non-standardness is not an excuse to take other people's tied up funds and destroy them permanently. There is some sort of crisis in the Bitcoin protocol stemming from the possible excessive usage of OP_CODESEPARTOR otherwise we wouldn't even be considering this soft fork. Fine. But presumably it is impossible for a transaction to both be produced in good faith for legitimate use and at the same time are expensive enough to be used as an attack vector, and hopefully there is a wide gap between these two cases. So let's draw a line between the two cases to rule out attacks while allowing legitimate uses by simply suitably pricing the OP_CODESEPARATOR opcode by weight. At worst case this moderately-large transaction is very expensive, reflecting its true cost, or is was so expensive that it couldn't possibly have been legitimate to begin with since the resources to validate it exceed the amount that are reasonable to validate an entire block of regular transactions. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190308/b6349b97/attachment-0001.html>