From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 2D701C04E for ; Fri, 8 Mar 2019 15:57:38 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io1-f41.google.com (mail-io1-f41.google.com [209.85.166.41]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 366CD12E for ; Fri, 8 Mar 2019 15:57:37 +0000 (UTC) Received: by mail-io1-f41.google.com with SMTP id k21so17076300ior.13 for ; Fri, 08 Mar 2019 07:57:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blockstream.io; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=D6TgfT3TVwkrdaSpWF04diM2EUB1ejeO1jwDwJkPKOw=; b=0Xnwu0C3QnKH+Hd304I/wMtsg0fNNlPHulVVYJgdNrnER2jtBPCna0NGCjOr6vblbw wlzl+3TvB65e571VARLz4fbPy/vctj1Y4lFLduP60601xgq9k2/pWGHjbFo8l5eVxJ5Z XUKl9SfroHVfgODWUDrNTLylzPxhhHgwIj3nQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=D6TgfT3TVwkrdaSpWF04diM2EUB1ejeO1jwDwJkPKOw=; b=Rg0hk/ehC1OSN+YjzhMky76mW5vJfNGBQShWRz0zbvKjutZaPc9dgr7ozJWgirVlcp fzXNyI8olkdcZ06NQ9xSds/yeLX6krakPC3Jr+Kf+wYKPfWRQVKPUZMPJaXxey8LzL9D jnm3TcIH85ycOR4VOR+mOonnKB3Ab2MRGJy968lxpa6W1Vv7sKdNNwgGi54ZxFjzCrb2 b4Olqe3QT+zQ36RLC8zkjEWmcUU+JDqC4UAHQwxPesidztq/kYlcsGjbhWZJxtMjGLD/ 8OskZV2HMRNknEZeQjJgfyuGK6xOo4MBxGLbu0WCJMcXaVsGqvwlTEDMGCtruUUydJFv uRag== X-Gm-Message-State: APjAAAWZeHm9+vy/E0IDPq+5WDO33pjwfY6EiNNDFsNUCoESXCg66hFU NZ6I/kYydYVspv7MMNdycJLIcLA/d/OFK3NxdQiKyy5u X-Google-Smtp-Source: APXvYqx8dMC7wYPoAyiCf1xyHUK4wBMY53WUx/fEBblLVLBQpz7L+9F5upp2GrXHcmPUrq8VV6yt6R5dYOQEfopcvqs= X-Received: by 2002:a6b:5905:: with SMTP id n5mr11183917iob.33.1552060656425; Fri, 08 Mar 2019 07:57:36 -0800 (PST) MIME-Version: 1.0 References: <6bb308f5-f478-d5ec-064f-e4972709f29c@mattcorallo.com> In-Reply-To: <6bb308f5-f478-d5ec-064f-e4972709f29c@mattcorallo.com> From: "Russell O'Connor" Date: Fri, 8 Mar 2019 10:57:25 -0500 Message-ID: To: Matt Corallo Content-Type: multipart/alternative; boundary="00000000000018cebf05839748da" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Fri, 08 Mar 2019 18:58:47 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 15:57:38 -0000 --00000000000018cebf05839748da Content-Type: text/plain; charset="UTF-8" On Thu, Mar 7, 2019 at 2:50 PM Matt Corallo 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> <2> CHECKMULTISIGVERIFY ELSE CODESEPARATOR 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. --00000000000018cebf05839748da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Mar 7, 2019 at 2:50 PM Matt Corallo <lf-lists@mattcorallo.com> = wrote:
Replies i= nline.

Matt

On 3/7/19 3:03 PM, Russell O'Connor wrote:
>
>=C2=A0 =C2=A0 =C2=A0* OP_CODESEPARATOR in non-BIP 143 scripts fails the= script validation.
>=C2=A0 =C2=A0 =C2=A0This includes OP_CODESEPARATORs in unexecuted branc= hes of if
>=C2=A0 =C2=A0 =C2=A0statements,
>=C2=A0 =C2=A0 =C2=A0similar to other disabled opcodes, but unlike OP_RE= TURN.
>
>
> OP_CODESEPARATOR is the only mechanism available that allows users to =
> sign which particular branch they are authorizing for within scripts <= br> > 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 practic= al script using OP_CODESEPARATOR.

IF <2> <= ;ALICEPUBKEY> <BOBPUBKEY> <2> CHECKMULTISIGVERIFY ELSE CODES= EPARATOR <ALICEPUBKEY> CHECKSIGVERFY ENDIF

<= div>Now when someone hands Alice, the CFO of XYZ corp., some transaction, s= he has the option of either signing it unilaterally herself, or creating a = partial signature such that the transaction additionally needs Bob, the CEO= s signature as well, and Alice's choice is committed to the blockchain = for auditing purposes later.

Now, there are ma= ny things you might object about this scheme, but my point is that (A) rega= rdless of what you think about this scheme, it, or similar schemes, may hav= e 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.
=C2=A0
> Because of P2SH you cannot know that no one is currently using this > feature.=C2=A0 Activating a soft-fork as describe above means these so= rts of
> funds would be permanently lost.=C2=A0 It is not acceptable to risk pe= ople'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.=C2=A0 I am not suggesting we don't fix = a vulnerability in Bitcoin.=C2=A0 I am suggesting we find another way.=C2= =A0 One that limits the of risk destroying other people's money.
<= div>
Here is a more concrete proposal:=C2=A0 No matter how ba= d OP_CODESEPARATOR is, it cannot be worse than instead including another in= put that spends another identically sized UTXO.=C2=A0 So how about we soft-= fork in a rule that says that an input's weight is increased by an amou= nt equal to the number of OP_CODESEPARATORs executed times the sum of weigh= t 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 exec= ute an OP_CODESEPARATOR after any CHECKSIG/CHECKMULTISIG operation", w= ould be vastly better than the current proposal, even though I would still = object to it.
=C2=A0
> I suggest an alternative whereby the execution of OP_CODESEPARATOR > increases the transactions weight suitably as to temper the
> vulnerability caused by it.=C2=A0 Alternatively there could be some so= rt 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 c= hanges to Bitcoin Core's default relay policy.=C2=A0 Non-standardness i= s not an excuse to take other people's tied up funds and destroy them p= ermanently.

There is some sort of crisis in the Bitcoin proto= col stemming from the possible excessive usage of OP_CODESEPARTOR otherwise= we wouldn't even be considering this soft fork.=C2=A0 Fine.=C2=A0 But = presumably it is impossible for a transaction to both be produced in good f= aith for legitimate use and at the same time are expensive enough to be use= d as an attack vector, and hopefully there is a wide gap between these two = cases.=C2=A0 So let's draw a line between the two cases to rule out att= acks while allowing legitimate uses by simply suitably pricing the OP_CODES= EPARATOR opcode by weight.=C2=A0 At worst case this moderately-large transa= ction is very expensive, reflecting its true cost, or is was so expensive t= hat it couldn't possibly have been legitimate to begin with since the r= esources to validate it exceed the amount that are reasonable to validate a= n entire block of regular transactions.
--00000000000018cebf05839748da--