Russell O'Connor [ARCHIVE] on Nostr: 📅 Original date posted:2019-03-08 📝 Original message:On Thu, Mar 7, 2019 at ...

📅 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>;