Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 2DD6E10B8 for ; 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 ; 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= header.from= 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 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: To: Russell O'Connor References: <702FE74C-119C-4D14-BCD3-85C4355356A2@xbt.hk> 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 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: 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 = wrote: >=20 > 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 = 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 " = 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. >=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

On 12 Dec 2018, at 6:50 AM, Russell O'Connor <roconnor@blockstream.io> wrote:

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 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.

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)).

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--