{"type":"rich","version":"1.0","author_name":"npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcu","author_url":"https://nostr.ae/npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcu","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2019-03-08\n📝 Original message:Replies inline.\n\nOn 3/8/19 3:57 PM, Russell O'Connor wrote:\n\u003e On Thu, Mar 7, 2019 at 2:50 PM Matt Corallo \u003clf-lists at mattcorallo.com \n\u003e \u003cmailto:lf-lists at mattcorallo.com\u003e\u003e wrote:\n\u003e It's very easy to construct a practical script using OP_CODESEPARATOR.\n\u003e \n\u003e IF \u003c2\u003e \u003cALICEPUBKEY\u003e \u003cBOBPUBKEY\u003e \u003c2\u003e CHECKMULTISIGVERIFY ELSE \n\u003e CODESEPARATOR \u003cALICEPUBKEY\u003e CHECKSIGVERFY ENDIF\n\u003e \n\u003e Now when someone hands Alice, the CFO of XYZ corp., some transaction, \n\u003e she has the option of either signing it unilaterally herself, or \n\u003e creating a partial signature such that the transaction additionally \n\u003e needs Bob, the CEOs signature as well, and Alice's choice is committed \n\u003e to the blockchain for auditing purposes later.\n\u003e \n\u003e Now, there are many things you might object about this scheme, but my \n\u003e point is that (A) regardless of what you think about this scheme, it, or \n\u003e similar schemes, may have been devised by users, and (B) users may have \n\u003e already committed funds to such schemes, and due to P2SH you cannot know \n\u003e that this is not the case.\n\nThe common way to set that up is to have a separate key, but, ok, fair \nenough. That said, the argument that \"it may be hidden by P2SH!\" isn't \nsufficient here. It has to *both* be hidden by P2SH and have never been \nspent from (either on mainnet or testnet) or be lock-timed a year in the \nfuture. I'm seriously skeptical that someone is using a highly esoteric \nscheme and has just been pouring money into it without ever having \ntested it or having withdrawn any money from it whatsoever. This is just \na weird argument.\n\n\n\u003e Please don't strawman my position.  I am not suggesting we don't fix a \n\u003e vulnerability in Bitcoin.  I am suggesting we find another way.  One \n\u003e that limits the of risk destroying other people's money.\n\u003e \n\u003e Here is a more concrete proposal:  No matter how bad OP_CODESEPARATOR \n\u003e is, it cannot be worse than instead including another input that spends \n\u003e another identically sized UTXO.  So how about we soft-fork in a rule \n\u003e that says that an input's weight is increased by an amount equal to the \n\u003e number of OP_CODESEPARATORs executed times the sum of weight of the UTXO \n\u003e being spent and 40 bytes, the weight of a stripped input. The risk of \n\u003e destroying other people's money is limited and AFAIU it would completely \n\u003e address the vulnerabilities caused by OP_CODESEPARATOR.\n\nYou're already arguing that someone has such an esoteric use of script, \nsuggesting they aren't *also* creating pre-signed, long-locktimed \ntransactions with many inputs isn't much of a further stretch \n(especially since this may result in the fee being non-standardly low if \nyou artificially increase its weight).\n\nNote that \"just limit number of OP_CODESEPARATOR calls\" results in a ton \nof complexity and reduces the simple analysis that fees (almost) have \ntoday vs just removing it allows us to also remove a ton of code.\n\nFurther note that if you don't remove it getting the efficiency wins \nright is even harder because instead of being able to cache sighashes \nyou now have to (at a minimum) wipe the cache between each \nOP_CODESEPARATOR call, which results in a ton of additional \nimplementation complexity.\n\n\u003e \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\n\u003e     sort of\n\u003e      \u003e limit (maybe 1) on the maximum number of OP_CODESEPARATORs\n\u003e     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\u003e \n\u003e I already know of people who's funds are tied up due to in other changes \n\u003e to Bitcoin Core's default relay policy.  Non-standardness is not an \n\u003e excuse to take other people's tied up funds and destroy them permanently.\n\nHuh?! The whole point of non-standardness in this context is to (a) make \nsoft-forking something out safer by derisking miners not upgrading right \naway and (b) signal something that may be a candidate for soft-forking \nout so that we get feedback. Who is getting things disabled who isn't \nbothering to *tell* people that their use-case is being hurt?!"}