path: root/6f/eba2ca9ec27c1226cff049ee40586a9997676d

Return-Path: <jl2012@xbt.hk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 2DD6E10B8
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 12 Dec 2018 19:53:49 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 229C674A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 12 Dec 2018 19:53:47 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; t=1544644424; cv=none; d=zoho.com; s=zohoarc; 
	b=h8Y8GuPxI8jlXtfc7WlLDQHcMdFYTjFzARQs8QZOMu3+DuMNM7kVIz8HXdFV3ViXd6GuB4inevYms/uBobY0bfoX6uBm4oSlk+D7cTVD7kJx6XahMPTZKD0O8IOah+u7KQpU27UfkkeXjfU2o4bhL47ZZ/I0v0GVBKffc5QhcJA=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com;
	s=zohoarc; t=1544644424;
	h=Content-Type:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To:ARC-Authentication-Results;
	bh=0jgNVPAuLmaPOCIm8lXKRQaNvELZ8rZZT+SVNDAN4xY=; 
	b=glkysqZI9U9E6NRIt+YmrRIcHs9fL8Km5u7gCHUChS/y9Js8uItQPBTkfK39ZLLjp1nnqVxsU8Vdo9WlJjUZ2a+4kMuW5NCJXJ++NusvzKE92orcu80Dxg4Ddp2b1rhVrBjVALyHgu6v+msDaWpYIp/ZKwJZsh61Q9myGThSF+o=
ARC-Authentication-Results: i=1; mx.zoho.com; dkim=pass  header.i=xbt.hk;
	spf=pass  smtp.mailfrom=jl2012@xbt.hk;
	dmarc=pass header.from=<jl2012@xbt.hk> header.from=<jl2012@xbt.hk>
Received: from [10.8.0.105] (n218103234118.netvigator.com [218.103.234.118])
	by mx.zohomail.com with SMTPS id 154464442332236.5328771140388;
	Wed, 12 Dec 2018 11:53:43 -0800 (PST)
From: Johnson Lau <jl2012@xbt.hk>
Message-Id: <864604F8-0BAF-403B-9A61-4788930F065F@xbt.hk>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_31206308-8284-460C-AB13-9E8AFD12C371"
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
Date: Thu, 13 Dec 2018 03:53:38 +0800
In-Reply-To: <CAMZUoKkYcXt7O39zdpz494f9Jm195mBtWyrH3siX4PBEAf8OKQ@mail.gmail.com>
To: Russell O'Connor <roconnor@blockstream.io>
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>
	<CAMZUoKkYcXt7O39zdpz494f9Jm195mBtWyrH3siX4PBEAf8OKQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.100.39)
X-ZohoMailClient: External
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,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: Thu, 13 Dec 2018 22:09:29 +0000
Cc: bitcoin-dev <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: Wed, 12 Dec 2018 19:53:49 -0000


--Apple-Mail=_31206308-8284-460C-AB13-9E8AFD12C371
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On 12 Dec 2018, at 6:50 AM, Russell O'Connor <roconnor@blockstream.io> =
wrote:
>=20
> On Sun, Dec 9, 2018 at 2:13 PM Johnson Lau <jl2012@xbt.hk =
<mailto: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 =
sighash 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.
>=20
> 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.
>=20
> Is there any script example that witness size malleability is =
unavoidable?
>=20
> 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.
>=20
> 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/c6db6ccdfa54571afee=
b582919240263424736a2/src/script.c#L718-L735>csv_2of3_then_2" Script =
<https://github.com/ElementsProject/libwally-core/blob/c6db6ccdfa54571afee=
b582919240263424736a2/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.
>=20
> 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)).

I think the root cause of witness weight malleability is some opcodes =
accept variable size input (without affecting the output), and that =
input is provided by the puzzle solver. Going through the opcode list, I =
think such opcodes include IF, NOTIF, VERIFY, DROP, 2DROP, NIP, DEPTH, =
and all arithmetic opcode that accepts CScriptNum (including =
CHECKMULTISIG)

VERIFY, DROP, 2DROP, NIP are not real problem, since they should not be =
the first opcode to interact with data directly provided by the puzzle =
solver.

CHECKMULTISIG is fixed by BIP147. For the key number and sig number, =
they should be part of the script, so not malleable.

DEPTH is a problem only if its inputs are not later examined by other =
opcodes. Again, this is pointless.

The liberally example should be protected by the MINIMAL_IF policy, =
which requires the input of OP_IF be minimal. As you note, OP_IF could =
be replaced by taproot in many cases

Non-minimal CScriptNum is also banned as BIP62 policy.

For the purpose of preventing malicious third party witness bloating, =
all we need is the miners to enforce the policy. There is no reason for =
miners to accept size malleated txs, as that will reduce the usable =
block space. If they hate a tx, they would simply drop it, instead of =
wasting the block space.



--Apple-Mail=_31206308-8284-460C-AB13-9E8AFD12C371
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" class=3D""><br =
class=3D""><div><br class=3D""><blockquote type=3D"cite" class=3D""><div =
class=3D"">On 12 Dec 2018, at 6:50 AM, Russell O'Connor &lt;<a =
href=3D"mailto:roconnor@blockstream.io" =
class=3D"">roconnor@blockstream.io</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" =
class=3D""><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"">On =
Sun, Dec 9, 2018 at 2:13 PM Johnson Lau &lt;<a =
href=3D"mailto:jl2012@xbt.hk" class=3D"">jl2012@xbt.hk</a>&gt; wrote:<br =
class=3D""></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex">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 sighash 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.<br class=3D"">
<br class=3D"">
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.<br class=3D"">
<br class=3D"">
Is there any script example that witness size malleability is =
unavoidable?<br class=3D""></blockquote><div class=3D""><br =
class=3D""></div><div class=3D"">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?&nbsp;&nbsp; But I admit there =
is a trade off:&nbsp; If we don't allow for signature covers weight, and =
we do need it, it will be too late to add.&nbsp; 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.&nbsp; =
However, I think the software complexity is relatively low, making it =
worthwhile.</div><div class=3D""><br class=3D""></div><div =
class=3D"">Moreover, even if witness weight malleability is entirely =
avoidable, it always seems to come at a cost.&nbsp; Taking as an example =
<a =
href=3D"https://github.com/ElementsProject/libwally-core/blob/c6db6ccdfa54=
571afeeb582919240263424736a2/src/script.c#L718-L735" class=3D"">libwally's=
 proposed "</a><span class=3D"gmail-pl-en"><a =
href=3D"https://github.com/ElementsProject/libwally-core/blob/c6db6ccdfa54=
571afeeb582919240263424736a2/src/script.c#L718-L735" =
class=3D"">csv_2of3_then_2" Script</a>, it begins with "<span =
class=3D"gmail-pl-c">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.&nbsp; Now to be fair, under Taproot this particular script's =
witness malleability problem probably goes away.&nbsp; 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.&nbsp; =
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.</span></span></div><div class=3D""><span =
class=3D"gmail-pl-en"><span class=3D"gmail-pl-c"><br =
class=3D""></span></span></div><div class=3D""><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.&nbsp; 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.&nbsp; 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)).<br =
class=3D""></span></span></div></div></div>
</div></blockquote></div><br class=3D""><div class=3D"">I think the root =
cause of witness weight malleability is some opcodes accept variable =
size input (without affecting the output), and that input is provided by =
the puzzle solver. Going through the opcode list, I think such opcodes =
include IF, NOTIF, VERIFY, DROP, 2DROP, NIP, DEPTH, and all arithmetic =
opcode that accepts CScriptNum (including CHECKMULTISIG)</div><div =
class=3D""><br class=3D""></div><div class=3D"">VERIFY, DROP, 2DROP, NIP =
are not real problem, since they should not be the first opcode to =
interact with data directly provided by the puzzle solver.</div><div =
class=3D""><br class=3D""></div><div class=3D"">CHECKMULTISIG is fixed =
by BIP147. For the key number and sig number, they should be part of the =
script, so not malleable.</div><div class=3D""><br class=3D""></div><div =
class=3D"">DEPTH is a problem only if its inputs are not later examined =
by other opcodes. Again, this is pointless.</div><div class=3D""><br =
class=3D""></div><div class=3D"">The liberally example should be =
protected by the MINIMAL_IF policy, which requires the input of OP_IF be =
minimal. As you note, OP_IF could be replaced by taproot in many =
cases</div><div class=3D""><br class=3D""></div><div =
class=3D"">Non-minimal CScriptNum is also banned as BIP62 =
policy.</div><div class=3D""><br class=3D""></div><div class=3D"">For =
the purpose of preventing malicious third party witness bloating, all we =
need is the miners to enforce the policy. There is no reason for miners =
to accept size malleated txs, as that will reduce the usable block =
space. If they hate a tx, they would simply drop it, instead of wasting =
the block space.</div><div class=3D""><br class=3D""></div><div =
class=3D""><br class=3D""></div></body></html>=

--Apple-Mail=_31206308-8284-460C-AB13-9E8AFD12C371--