{"type":"rich","version":"1.0","author_name":"npub1dw88wd5gqsqn6ufxhf9h03uk8087l7gfzdtez5csjlt6pupu4pwsj8plrw","author_url":"https://nostr.ae/npub1dw88wd5gqsqn6ufxhf9h03uk8087l7gfzdtez5csjlt6pupu4pwsj8plrw","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2019-03-08\n📝 Original message:On Thu, Mar 7, 2019 at 2:50 PM Matt Corallo \u003clf-lists at mattcorallo.com\u003e\nwrote:\n\n\u003e Replies inline.\n\u003e\n\u003e Matt\n\u003e\n\u003e On 3/7/19 3:03 PM, Russell O'Connor wrote:\n\u003e \u003e\n\u003e \u003e     * OP_CODESEPARATOR in non-BIP 143 scripts fails the script\n\u003e validation.\n\u003e \u003e     This includes OP_CODESEPARATORs in unexecuted branches of if\n\u003e \u003e     statements,\n\u003e \u003e     similar to other disabled opcodes, but unlike OP_RETURN.\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e OP_CODESEPARATOR is the only mechanism available that allows users to\n\u003e \u003e sign which particular branch they are authorizing for within scripts\n\u003e \u003e that have multiple possible conditions that reuse the same public key.\n\u003e\n\u003e This is true, and yet it does not appear to actually be practically\n\u003e usable. Thus far, despite a ton of effort, I have not yet seen a\n\u003e practical use-case for OP_CODESEPARATOR (except for one example of it\n\u003e being used to make SegWit scripts ever-so-slightly more effecient in\n\u003e TumbleBit, hence why this BIP does not propose disabling it for SegWit).\n\u003e\n\nIt's very easy to construct a practical script using OP_CODESEPARATOR.\n\nIF \u003c2\u003e \u003cALICEPUBKEY\u003e \u003cBOBPUBKEY\u003e \u003c2\u003e CHECKMULTISIGVERIFY ELSE CODESEPARATOR\n\u003cALICEPUBKEY\u003e CHECKSIGVERFY ENDIF\n\nNow when someone hands Alice, the CFO of XYZ corp., some transaction, she\nhas the option of either signing it unilaterally herself, or creating a\npartial signature such that the transaction additionally needs Bob, the\nCEOs signature as well, and Alice's choice is committed to the blockchain\nfor auditing purposes later.\n\nNow, there are many things you might object about this scheme, but my point\nis that (A) regardless of what you think about this scheme, it, or similar\nschemes, may have been devised by users, and (B) users may have already\ncommitted funds to such schemes, and due to P2SH you cannot know that this\nis not the case.\n\n\n\u003e \u003e Because of P2SH you cannot know that no one is currently using this\n\u003e \u003e feature.  Activating a soft-fork as describe above means these sorts of\n\u003e \u003e funds would be permanently lost.  It is not acceptable to risk people's\n\u003e \u003e money like this.\n\u003e\n\u003e (1) It has been well documented again and again that there is desire to\n\u003e remove OP_CODESEPARATOR, (2) it is well-documented OP_CODESEPARATOR in\n\u003e non-segwit scripts represents a rather significant vulnerability in\n\u003e Bitcoin today, and (3) lots of effort has gone into attempting to find\n\u003e practical use-cases for OP_CODESEPARATOR's specific construction, with\n\u003e no successes as of yet. I strongly, strongly disagree that the\n\u003e highly-unlikely remote possibility that someone created something before\n\u003e which could be rendered unspendable is sufficient reason to not fix a\n\u003e vulnerability in Bitcoin today.\n\u003e\n\nPlease don't strawman my position.  I am not suggesting we don't fix a\nvulnerability in Bitcoin.  I am suggesting we find another way.  One that\nlimits the of risk destroying other people's money.\n\nHere is a more concrete proposal:  No matter how bad OP_CODESEPARATOR is,\nit cannot be worse than instead including another input that spends another\nidentically sized UTXO.  So how about we soft-fork in a rule that says that\nan input's weight is increased by an amount equal to the number of\nOP_CODESEPARATORs executed times the sum of weight of the UTXO being spent\nand 40 bytes, the weight of a stripped input. The risk of destroying other\npeople's money is limited and AFAIU it would completely address the\nvulnerabilities caused by OP_CODESEPARATOR.\n\nEven soft forking a rule like, \"it is illegal to execute an\nOP_CODESEPARATOR after any CHECKSIG/CHECKMULTISIG operation\", would be\nvastly better than the current proposal, even though I would still object\nto it.\n\n\n\u003e \u003e I suggest an alternative whereby the execution of OP_CODESEPARATOR\n\u003e \u003e increases the transactions weight suitably as to temper the\n\u003e \u003e vulnerability caused by it.  Alternatively there could be some sort of\n\u003e \u003e limit (maybe 1) on the maximum number of OP_CODESEPARATORs allowed to be\n\u003e \u003e executed per script, but that would require an argument as to why\n\u003e \u003e exceeding that limit isn't reasonable.\n\u003e\n\u003e You could equally argue, however, that any such limit could render some\n\u003e moderately-large transaction unspendable, so I'm somewhat skeptical of\n\u003e this argument. Note that OP_CODESEPARATOR is non-standard, so getting\n\u003e them mined is rather difficult in any case.\n\u003e\n\nI already know of people who's funds are tied up due to in other changes to\nBitcoin Core's default relay policy.  Non-standardness is not an excuse to\ntake other people's tied up funds and destroy them permanently.\n\nThere is some sort of crisis in the Bitcoin protocol stemming from the\npossible excessive usage of OP_CODESEPARTOR otherwise we wouldn't even be\nconsidering this soft fork.  Fine.  But presumably it is impossible for a\ntransaction to both be produced in good faith for legitimate use and at the\nsame time are expensive enough to be used as an attack vector, and\nhopefully there is a wide gap between these two cases.  So let's draw a\nline between the two cases to rule out attacks while allowing legitimate\nuses by simply suitably pricing the OP_CODESEPARATOR opcode by weight.  At\nworst case this moderately-large transaction is very expensive, reflecting\nits true cost, or is was so expensive that it couldn't possibly have been\nlegitimate to begin with since the resources to validate it exceed the\namount that are reasonable to validate an entire block of regular\ntransactions.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190308/b6349b97/attachment-0001.html\u003e"}