path: root/df/3a78c9743964e628a239f7a82f3af346d21549

Return-Path: <roconnor@blockstream.io>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 9602A9E2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 11 Dec 2018 22:50:37 +0000 (UTC)
Received: by mail-io1-f47.google.com with SMTP id m19so13279707ioh.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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: <CAPg+sBhuPG-2GXc+Bp0yv5ywry2fk56LPLT4AY0Kcs+YEoz4FA@mail.gmail.com>
	<CAPg+sBiu0BjZEtz-t7m3M+TnAEDG_k1GKtxwkOKh6qrSezUO7g@mail.gmail.com>
	<CAMZUoKkJdU0P_dVRvHn5zY6xUHYUptdK221ioQMp3FXZAerp3Q@mail.gmail.com>
	<702FE74C-119C-4D14-BCD3-85C4355356A2@xbt.hk>
In-Reply-To: <702FE74C-119C-4D14-BCD3-85C4355356A2@xbt.hk>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Tue, 11 Dec 2018 17:50:24 -0500
Message-ID: <CAMZUoKkYcXt7O39zdpz494f9Jm195mBtWyrH3siX4PBEAf8OKQ@mail.gmail.com>
To: Johnson Lau <jl2012@xbt.hk>
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 <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <jl2012@xbt.hk> 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 "
<https://github.com/ElementsProject/libwally-core/blob/c6db6ccdfa54571afeeb=
582919240263424736a2/src/script.c#L718-L735>csv_2of3_then_2"
Script
<https://github.com/ElementsProject/libwally-core/blob/c6db6ccdfa54571afeeb=
582919240263424736a2/src/script.c#L718-L735>,
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

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Sun, Dec 9,=
 2018 at 2:13 PM Johnson Lau &lt;<a href=3D"mailto:jl2012@xbt.hk">jl2012@xb=
t.hk</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
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.<br>
<br>
Is there any script example that witness size malleability is unavoidable?<=
br></blockquote><div><br></div><div>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&#39;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&#39;ve added that software complexity for no gain.=C2=A0 However, I=
 think the software complexity is relatively low, making it worthwhile.</di=
v><div><br></div><div>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 <a href=3D"https://github.com/ElementsProject/libwally-core/blob/c6db6cc=
dfa54571afeeb582919240263424736a2/src/script.c#L718-L735">libwally&#39;s pr=
oposed &quot;</a><span class=3D"gmail-pl-en"><a href=3D"https://github.com/=
ElementsProject/libwally-core/blob/c6db6ccdfa54571afeeb582919240263424736a2=
/src/script.c#L718-L735">csv_2of3_then_2&quot; Script</a>, it begins with &=
quot;<span class=3D"gmail-pl-c">OP_DEPTH OP_1SUB OP_1SUB&quot; 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&#39;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.</span></span=
></div><div><span class=3D"gmail-pl-en"><span class=3D"gmail-pl-c"><br></sp=
an></span></div><div><span class=3D"gmail-pl-en"><span class=3D"gmail-pl-c"=
>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)).<br></span></span></div></div></div>

--000000000000ef42f1057cc6e8c9--