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 63241D88 for ; Thu, 13 Dec 2018 16:50:23 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-it1-f174.google.com (mail-it1-f174.google.com [209.85.166.174]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B01167C3 for ; Thu, 13 Dec 2018 16:50:22 +0000 (UTC) Received: by mail-it1-f174.google.com with SMTP id z7so4686553iti.0 for ; Thu, 13 Dec 2018 08:50:22 -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=RfteMk0A/UunasAhYOHs8jaSRXoCziux4JUSr3j5uQE=; b=YmFH5NJXC35THoQx6D7AI8AhYvmdlguWV8R/z8ZI0A7G0b7FDPD1EeweZj/aKxnJ6b KslSbL5FWxL1uFkjEPoiuDMYiviiChkcsCA3owGCDtdSDcbfF+jjkQ5Ci6RAUsoveLqb YUdk/xknhecg6E893nPcU5WYeJLXa11iIDxPU= 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=RfteMk0A/UunasAhYOHs8jaSRXoCziux4JUSr3j5uQE=; b=GkerDtQE00YF7KfQ0t+1s6MP9x93AUGRV1+f+eCt4OfCt8yfy7QCtFHzaBnK56km8m gPxrjcoJCwO/Cmqeey+qXiZBmoRBv1HOxitVkc2rfo2LiXLFtu5HvVPi7Jumcn7alPD5 6hSwizVQs/RWSrrBsHpLy1bDbgW79MIkoq4MpH2yFyI4QzMYXIpM2NKezjSe5xb5jY+T 4eRKWQ6DpyidemwgGtoO63+eylHFavL3EjuGk5vxpOpVVmRR+KtNKo5hhzVfrVXv0p3v GL0J52SIz23Jq9CcRcu0v2jRUSsMl/+IPrWefVRYyUamtL4dm0Dd14DHAw1uJnWVYNHI R0qg== X-Gm-Message-State: AA+aEWZGsH/J3x/TMLJAshgCQo0YMisbsKJnqS+2YtMwDvTkLs2nuvW9 bW/JsHxwo4cxt5Bn3KGeG0p+1Xcl+uNaZdhuN7ZX4Q== X-Google-Smtp-Source: AFSGD/VGAfY2YEKDsDVTWKw60VB+MN5lqyROg4bp29PpfOxGyFZKJZCChsGPV4jklrtrBJ+6z47K+Xe1Jk/8lc0WQSc= X-Received: by 2002:a02:3da:: with SMTP id e87mr21903345jae.78.1544719821795; Thu, 13 Dec 2018 08:50:21 -0800 (PST) MIME-Version: 1.0 References: <702FE74C-119C-4D14-BCD3-85C4355356A2@xbt.hk> <864604F8-0BAF-403B-9A61-4788930F065F@xbt.hk> In-Reply-To: <864604F8-0BAF-403B-9A61-4788930F065F@xbt.hk> From: "Russell O'Connor" Date: Thu, 13 Dec 2018 11:50:10 -0500 Message-ID: To: Johnson Lau Content-Type: multipart/alternative; boundary="000000000000418a23057cea1ce0" 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: Thu, 13 Dec 2018 22:09:29 +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: Thu, 13 Dec 2018 16:50:23 -0000 --000000000000418a23057cea1ce0 Content-Type: text/plain; charset="UTF-8" On Wed, Dec 12, 2018 at 2:53 PM Johnson Lau wrote: > > 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. > I don't know if it such a clear cut case for miner's policy. A miner is passed a malleated tx. They know that there is probably a non-malleated variant floating around out there somewhere, and they would rather have it. But right now they don't, and they probably not going to try to unmalleate it themselves. So, why not stick it into their mempool? If it eventually makes it into one of their blocks, then it will because it has the best fee rate available, and to reject it outright is harmful to their bottom line. If they find the non-malleated variant later, great, they can replace it and gain a higher-fee rate tx. Of course, such a policy opens them up to a Denial of Service attack. So what do they do? Do they accept malleated tx's and implement an RBF policy that requires sufficient fee rate increases? Do they reject malleated txs outright to avoid falling in this trap in the first place as you suggest? I don't know, but I don't think things are as clear cut as you present. That aside, your list of weight malleable opcodes is shorter than I imagined and I'm grateful you've compiled it. Perhaps the best solution is to make MINIMAL_IF and minimal CScriptNum consensus enforced in the next version of Script and all but eliminate weight malleability in practice? --000000000000418a23057cea1ce0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed= , Dec 12, 2018 at 2:53 PM Johnson Lau <= jl2012@xbt.hk> wrote:

I think= the root cause of witness weight malleability is some opcodes accept varia= ble size input (without affecting the output), and that input is provided b= y the puzzle solver. Going through the opcode list, I think such opcodes in= clude 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 th= e first opcode to interact with data directly provided by the puzzle solver= .

CHECKMULTISIG is fixed by BIP147. For the key nu= mber 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.

<= div>The liberally example should be protected by the MINIMAL_IF policy, whi= ch requires the input of OP_IF be minimal. As you note, OP_IF could be repl= aced by taproot in many cases

Non-minimal CScriptN= um is also banned as BIP62 policy.

For the purpose= of preventing malicious third party witness bloating, all we need is the m= iners to enforce the policy. There is no reason for miners to accept size m= alleated 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.

I don't know if it such a clear cut c= ase for miner's policy.=C2=A0 A miner is passed a malleated tx.=C2=A0 T= hey know that there is probably a non-malleated variant floating around out= there somewhere, and they would rather have it.=C2=A0 But right now they d= on't, and they probably not going to try to unmalleate it themselves.= =C2=A0 So, why not stick it into their mempool?=C2=A0 If it eventually make= s it into one of their blocks, then it will because it has the best fee rat= e available, and to reject it outright is harmful to their bottom line.=C2= =A0 If they find the non-malleated variant later, great, they can replace i= t and gain a higher-fee rate tx.=C2=A0 Of course, such a policy opens them = up to a Denial of Service attack.

So what do they = do?=C2=A0 Do they accept malleated tx's and implement an RBF policy tha= t requires sufficient fee rate increases?=C2=A0 Do they reject malleated tx= s outright to avoid falling in this trap in the first place as you suggest?= =C2=A0 I don't know, but I don't think things are as clear cut as y= ou present.


That aside, your list o= f weight malleable opcodes is shorter than I imagined and I'm grateful = you've compiled it.=C2=A0 Perhaps the best solution is to make MINIMAL_= IF and minimal CScriptNum consensus enforced in the next version of Script = and all but eliminate weight malleability in practice?
--000000000000418a23057cea1ce0--