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 B85E4499 for ; Sun, 1 Oct 2017 19:42:10 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ua0-f177.google.com (mail-ua0-f177.google.com [209.85.217.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 67D083F9 for ; Sun, 1 Oct 2017 19:42:08 +0000 (UTC) Received: by mail-ua0-f177.google.com with SMTP id g34so2217345uah.7 for ; Sun, 01 Oct 2017 12:42:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blockstream-io.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WVMWfC+KS9pVL9SEcrlvy1blQOpVI25K5aohh25F0Q0=; b=LfNWtGWLZ/LuAyIqPtyZjegQjgGrJczkgQb+1IrYAOH9xIqm7TkqcIYse4jD7lMcwG JkCFXQFPOWXoMb1TfQ0TPKfF53xn506YqgpqiMo8+559ifbe+thkn/IJXbHnZR5vf2O7 1XwcYFfirDwt9BUA1wuX0hlYZVKdMEkb02Dn3RZdxJ86msSshjwQVltgvjAvCuv2vynq F0RlKed9IlIEkQHR1v5j/HW+3u9rsR20R0pFoFcZArx0kmgB4gNUnDDZ1eCVtFtWRl2t TYyjUb0w44kVecAaHBJ5hK4h+6rm1uM9W7Wxnsrx44DuDN9M++7Xl3h3y4dCTd4OAlv7 mz6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WVMWfC+KS9pVL9SEcrlvy1blQOpVI25K5aohh25F0Q0=; b=I2q9bLb8gzCrvYtCdPaFiLYNiPwm50qB/6zhgurwt1BTSyiMIDGMl+0Ki0eBUApxIG 1TwTXa7hLWMufH7+WztCw1sdaoVQwzYuAKJmbVYFEpOTEsBh0BANkrSKNDMdNYaKf+7F 5nJWPfts9TcumFHSQhsWUQplnDTtICfrzSaokQ429Bvr2s3+0W1WZqTNhmp/B2rXdKOl dJSxltVpnI5ejN97uhZPmuyRlD319WVAPAJCUwfLo+hClQAUJNL+felOqAiukH0qRFR1 luSYRsPZfvsPLopDiXiuzeDwZXSgQ/RaMjXDg0/fhRecydVLpRY4lDNXwNvOXrSiGrnI 87kQ== X-Gm-Message-State: AHPjjUgT1Ts/krBLT3ootTYIeDNpjWesoLZ0W/9JGo4g+RKtMmDj0qCl dc/ycib1oYBclZi6sYk5imb733d+NNg4mAzxD9uuDg== X-Google-Smtp-Source: AOwi7QC71gnGnfkrJDsB8b4nlXlzwzfZSODRdDqL7mkmzIusG906Y2Gay0JkJLaJGuDQ46oYvgfNMH8HjJQLSjqT6no= X-Received: by 10.159.37.201 with SMTP id 67mr7785392uaf.59.1506886927056; Sun, 01 Oct 2017 12:42:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.41.161 with HTTP; Sun, 1 Oct 2017 12:41:46 -0700 (PDT) In-Reply-To: <460EDF1F-2BFD-4DBE-A921-73469C2EA9B9@friedenbach.org> References: <201710010113.30518.luke@dashjr.org> <5A220A8D-3A85-49D0-8DB2-6BDEC362EAEB@friedenbach.org> <201710010247.42180.luke@dashjr.org> <460EDF1F-2BFD-4DBE-A921-73469C2EA9B9@friedenbach.org> From: "Russell O'Connor" Date: Sun, 1 Oct 2017 15:41:46 -0400 Message-ID: To: Mark Friedenbach Content-Type: multipart/alternative; boundary="001a113c4f3c011567055a817472" X-Spam-Status: No, score=0.5 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=disabled version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Version 1 witness programs (first draft) 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: Sun, 01 Oct 2017 19:42:10 -0000 --001a113c4f3c011567055a817472 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Oct 1, 2017 at 3:27 PM, Mark Friedenbach wrote: > > On Oct 1, 2017, at 12:05 PM, Russell O'Connor > wrote: > > > > Given the proposed fixed signature size, It seems better to me that we > create a SIGHASH_WITNESS_WEIGHT flag as opposed to SIGHASH_WITNESS_DEPTH. > > For what benefit? If your script actually uses all the items on the stack= , > and if your script is not written in such a way as to allow malleability > (which cannot be prevented in general), then they=E2=80=99re equivalent. = Using > weight instead of depth only needlessly restricts other parties to select= a > witness size up-front. > Creating a Bitcoin script that does not allow malleability is difficult and requires wasting a lot of bytes to do so, typically when handling issues around non-0-or-1 witness values being used with OP_IF, and dealing with non-standard-zero values, etc. Adding a witness weight flag cuts through the worst of all this, and makes script design enormously simpler and makes scripts smaller and cheaper. > And to be clear, signing witness weight doesn=E2=80=99t mean the witness = is not > malleable. The signer could sign again with a different ECDSA nonce. Or i= f > the signer is signing from a 2-of-3 wallet, a common scenario I hope, the= re > are 3 possible key combinations that could be used. If using MBV, a > 3-element tree is inherently unbalanced and the common use case can have = a > smaller proof size. > > Witnesses are not 3rd party malleable and we will maintain that property > going forward with future opcodes. > > > Mark, you seem to be arguing that in general we still want weight > malleability even with witness depth fixed, but I don't understand in wha= t > scenario we would want that. > > Any time all parties are not online at the same time in an interactive > signing protocol, or for which individual parties have to reconfigure the= ir > signing choices due to failures. We should not restrict our script > signature system to such a degree that it becomes difficult to create > realistic signing setups for people using best practices (multi-key, 2FA, > etc.) to sign. If I am a participant in a signing protocol, it would be > layer violating to treat me as anything other than a black box, such that > internal errors and timeouts in my signing setup don=E2=80=99t propagate = upwards to > the multi-party protocol. > > For example, I should be able to try to 2FA sign, and if that fails go > fetch my backup key and sign with that. But because it=E2=80=99s my infre= quently > used backup key, it might be placed deeper in the key tree and therefore > signatures using it are larger. All the other signers need care is that > slot #3 in the witness is where my Merkle proof goes. They shouldn=E2=80= =99t have > to restart and resign because my proof was a little larger than anticipat= ed > =E2=80=94 and maybe they can=E2=80=99t resign because double-spend protec= tions! > I'll argue that I don't want my counter-party going off and using a very deeply nested key in order to subvert the fee rate we've agreed upon after I've signed my part of the input. If we are doing multi-party signing of inputs we need to communicate anyways to construct the transaction. I see no problem with requiring my counter-party to choose their keys before I sign so that I know up front what our fee rate is going to be. If they lose their keys and need a backup, they should have to come back to me to resign in order that we can negotiate a new fee rate for the transaction and who is going to be covering how much of the fee and on which inputs. --001a113c4f3c011567055a817472 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= un, Oct 1, 2017 at 3:27 PM, Mark Friedenbach <mark@friedenbach.org= > wrote:
> = On Oct 1, 2017, at 12:05 PM, Russell O'Connor <roconnor@blockstream.io> wrote:
>
> Given the proposed fixed signature size, It seems better to me that we= create a SIGHASH_WITNESS_WEIGHT flag as opposed to SIGHASH_WITNESS_DEPTH.<= br>
For what benefit? If your script actually uses all the items on the = stack, and if your script is not written in such a way as to allow malleabi= lity (which cannot be prevented in general), then they=E2=80=99re equivalen= t. Using weight instead of depth only needlessly restricts other parties to= select a witness size up-front.

Creati= ng a Bitcoin script that does not allow malleability is difficult and requi= res wasting a lot of bytes to do so, typically when handling issues around = non-0-or-1 witness values being used with OP_IF, and dealing with non-stand= ard-zero values, etc.=C2=A0 Adding a witness weight flag cuts through the w= orst of all this, and makes script design enormously simpler and makes scri= pts smaller and cheaper.
=C2=A0
And to be clear, signing witness weight doesn=E2=80=99t mean the witness is= not malleable. The signer could sign again with a different ECDSA nonce. O= r if the signer is signing from a 2-of-3 wallet, a common scenario I hope, = there are 3 possible key combinations that could be used. If using MBV, a 3= -element tree is inherently unbalanced and the common use case can have a s= maller proof size.

Witnesses are not 3rd party malleable and we will maintain that property go= ing forward with future opcodes.

> Mark, you seem to be arguing that in general we still want weight mall= eability even with witness depth fixed, but I don't understand in what = scenario we would want that.

Any time all parties are not online at the same time in an interacti= ve signing protocol, or for which individual parties have to reconfigure th= eir signing choices due to failures. We should not restrict our script sign= ature system to such a degree that it becomes difficult to create realistic= signing setups for people using best practices (multi-key, 2FA, etc.) to s= ign. If I am a participant in a signing protocol, it would be layer violati= ng to treat me as anything other than a black box, such that internal error= s and timeouts in my signing setup don=E2=80=99t propagate upwards to the m= ulti-party protocol.

For example, I should be able to try to 2FA sign, and if that fails go fetc= h my backup key and sign with that. But because it=E2=80=99s my infrequentl= y used backup key, it might be placed deeper in the key tree and therefore = signatures using it are larger. All the other signers need care is that slo= t #3 in the witness is where my Merkle proof goes. They shouldn=E2=80=99t h= ave to restart and resign because my proof was a little larger than anticip= ated =E2=80=94 and maybe they can=E2=80=99t resign because double-spend pro= tections!

I'll argue that I don'= ;t want my counter-party going off and using a very deeply nested key in or= der to subvert the fee rate we've agreed upon after I've signed my = part of the input.=C2=A0 If we are doing multi-party signing of inputs we n= eed to communicate anyways to construct the transaction.=C2=A0 I see no pro= blem with requiring my counter-party to choose their keys before I sign so = that I know up front what our fee rate is going to be.=C2=A0 If they lose t= heir keys and need a backup, they should have to come back to me to resign = in order that we can negotiate a new fee rate for the transaction and who i= s going to be covering how much of the fee and on which inputs.

--001a113c4f3c011567055a817472--