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 9602A9E2 for ; Tue, 11 Dec 2018 22:50:38 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io1-f47.google.com (mail-io1-f47.google.com [209.85.166.47]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C88AC850 for ; Tue, 11 Dec 2018 22:50:37 +0000 (UTC) Received: by mail-io1-f47.google.com with SMTP id m19so13279707ioh.3 for ; Tue, 11 Dec 2018 14:50: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=ziQwUyTfS/iGsmgps6jRG17IbsOffDVLYuOnGVCftZo=; b=QKtf8Lcv9gS1iqjaiH3691McsR8hibGxZSDAQMs/wt8nYR6C/kC0yJxu72E5ibYgD7 DSgBqYcy9qfIYskfwls2mTAiJDIyVL7hr8KEQH0TzAiUppy54SeyyetX90v0O33/XWM3 RXULxxIzZmoY1vtJaoSvnm5C4DBgtWPLyoyZk= 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=ziQwUyTfS/iGsmgps6jRG17IbsOffDVLYuOnGVCftZo=; b=CafHJEWwNGkz1Yd3gG+Nklo2IySG7yipSjYG5uICGH0Vb7QXaNWb41XzOorIsmXdrm oEKPld5Yz9psXoV//vJqDNCYDnO2iUMgvcDjaHemf1knh3rUxOzf3IBFdATY8LkuYKh1 PxELIlT+dEG0g1DJ1X3GGcn2MlC0/e6k6AaZXF+lNPP56bA6IgrLjwtoGso5H0GfAnrP 35afRN8UOqLoAlacWA84JEpKZCYOSaSVP4O3fkNLa0FmlxtRFjNsFVLC5wI6O1VJ0uK0 tnqdhMZrHn6C9bCUPIIGnTMtKgneMP7DkL38VfajAV5Y9qUuAOjiVIbQO18HNKvqN/yA e+tQ== X-Gm-Message-State: AA+aEWZ8TyGyrjnTj3e6d2xLyPHt6h3yGumKlAPeAAnW5G1h7h7Zr72y Oto5480ruqPVWlSOySQ8x6QaelU5L4CtsJCLGmP81w== X-Google-Smtp-Source: AFSGD/VR3cKDDs4kxnW2h6Yj8jNtJkn32o0DsMKdMqusmmKbDLtbBJlJgo5Fdhl83anEFTw8MidiUOpg/T6GI36YKD8= X-Received: by 2002:a6b:ec15:: with SMTP id c21mr16375439ioh.33.1544568636909; Tue, 11 Dec 2018 14:50:36 -0800 (PST) MIME-Version: 1.0 References: <702FE74C-119C-4D14-BCD3-85C4355356A2@xbt.hk> In-Reply-To: <702FE74C-119C-4D14-BCD3-85C4355356A2@xbt.hk> From: "Russell O'Connor" Date: Tue, 11 Dec 2018 17:50:24 -0500 Message-ID: To: Johnson Lau Content-Type: multipart/alternative; boundary="000000000000ef42f1057cc6e8c9" 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: Wed, 12 Dec 2018 17:12:38 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT 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: Tue, 11 Dec 2018 22:50:38 -0000 --000000000000ef42f1057cc6e8c9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Dec 9, 2018 at 2:13 PM Johnson Lau wrote: > The current proposal is that a 64-byte signature will be used for the > default =E2=80=9Csigning all=E2=80=9D sighash, and 65-byte for other sigh= ash types. The > space saved will allow a few more txs in a block, so I think it worths > doing. However, this also makes witness weight estimation more difficult = in > multisig cases. > > This idea of signing witness weight has been brought up before. I think > the concern is the difficulty to estimate the witness weight for complex > scripts, which need this feature most. So it will work when it is not > needed, and will not work when it is needed. > > Is there any script example that witness size malleability is unavoidable= ? > I tend to think in opposite terms. Is there a proof that any script can be transformed into an equivalent one that avoids witness weight malleability? But I admit there is a trade off: If we don't allow for signature covers weight, and we do need it, it will be too late to add. On the other hand if we add signature covers weight, but it turns out that no Script ever needs to use it, then we've added that software complexity for no gain. However, I think the software complexity is relatively low, making it worthwhile. Moreover, even if witness weight malleability is entirely avoidable, it always seems to come at a cost. Taking as an example libwally's proposed " csv_2of3_then_2" Script , it begins with "OP_DEPTH OP_1SUB OP_1SUB" spending 3 vbytes to avoid any possible witness malleability versus just taking a witness stack item to determine the branch, costing 1 or 2 (unmalleated) vbytes. Now to be fair, under Taproot this particular script's witness malleability problem probably goes away. Nonetheless, I think it is fair to say that Bitcoin Script was designed without any regard given to scriptSig/witness malleability concerns and the result is that one is constantly fighting against malleability issues. Short of a wholesale replacement of Bitcoin Script, I do think that having an option for signature covers weight is one of the best ways to address the whole problem. Regarding your point about 64/65-byte signatures; I speculate that in most protocols, all parties that are able to consider signing the weight, know what sighash flags the other parties are expected to be using. However, your point is well-taken, and if we choose to adopt the option of signatures covering weight, we ought to make sure there exists a 65-byte signature that performs the equivalent of a sigHashAll (of course, still covering that particular sighash flag under the signature), to ensure that anti-weight-malleability can be use even when the sighash flags that other parties will use are unknown. Even with the extra vbytes in the signatures, there may be a net weight savings by avoiding the need for anti-malleability Script code. (It might also be reasonable to have participants create signatures for a small range of different weight values? (Sorry in advance to PSBT)). --000000000000ef42f1057cc6e8c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Dec 9,= 2018 at 2:13 PM Johnson Lau <jl2012@xb= t.hk> wrote:
The current pro= posal is that a 64-byte signature will be used for the default =E2=80=9Csig= ning all=E2=80=9D sighash, and 65-byte for other sighash types. The space s= aved will allow a few more txs in a block, so I think it worths doing. Howe= ver, this also makes witness weight estimation more difficult in multisig c= ases.

This idea of signing witness weight has been brought up before. I think the= concern is the difficulty to estimate the witness weight for complex scrip= ts, which need this feature most. So it will work when it is not needed, an= d will not work when it is needed.

Is there any script example that witness size malleability is unavoidable?<= br>

I tend to think in opposite terms. Is t= here a proof that any script can be transformed into an equivalent one that= avoids witness weight malleability?=C2=A0=C2=A0 But I admit there is a tra= de off:=C2=A0 If we don't allow for signature covers weight, and we do = need it, it will be too late to add.=C2=A0 On the other hand if we add sign= ature covers weight, but it turns out that no Script ever needs to use it, = then we've added that software complexity for no gain.=C2=A0 However, I= think the software complexity is relatively low, making it worthwhile.

Moreover, even if witness weight malleability is enti= rely avoidable, it always seems to come at a cost.=C2=A0 Taking as an examp= le libwally's pr= oposed "csv_2of3_then_2" Script, it begins with &= quot;OP_DEPTH OP_1SUB OP_1SUB" spending 3 v= bytes to avoid any possible witness malleability versus just taking a witne= ss stack item to determine the branch, costing 1 or 2 (unmalleated) vbytes.= =C2=A0 Now to be fair, under Taproot this particular script's witness m= alleability problem probably goes away.=C2=A0 Nonetheless, I think it is fa= ir to say that Bitcoin Script was designed without any regard given to scri= ptSig/witness malleability concerns and the result is that one is constantl= y fighting against malleability issues.=C2=A0 Short of a wholesale replacem= ent of Bitcoin Script, I do think that having an option for signature cover= s weight is one of the best ways to address the whole problem.

Regarding your point about 64/65-byte signatures; I speculate that in most= protocols, all parties that are able to consider signing the weight, know = what sighash flags the other parties are expected to be using.=C2=A0 Howeve= r, your point is well-taken, and if we choose to adopt the option of signat= ures covering weight, we ought to make sure there exists a 65-byte signatur= e that performs the equivalent of a sigHashAll (of course, still covering t= hat particular sighash flag under the signature), to ensure that anti-weigh= t-malleability can be use even when the sighash flags that other parties wi= ll use are unknown.=C2=A0 Even with the extra vbytes in the signatures, the= re may be a net weight savings by avoiding the need for anti-malleability S= cript code. (It might also be reasonable to have participants create signat= ures for a small range of different weight values? (Sorry in advance to PSB= T)).
--000000000000ef42f1057cc6e8c9--