path: root/0f/f00a2369be1194ca907cf4b31df752fe0b6506

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 E7C98AC7
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  6 Dec 2018 16:57:23 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-it1-f170.google.com (mail-it1-f170.google.com
	[209.85.166.170])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2EED97FC
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  6 Dec 2018 16:57:21 +0000 (UTC)
Received: by mail-it1-f170.google.com with SMTP id g76so2439248itg.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 06 Dec 2018 08:57:21 -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; 
	bh=kmv+mhDe+TmcsJDh40om1ZpkYc2YZWIDCOf22RF0h4c=;
	b=Z4F7otqIa+bUYCZv9ceLAjiOe+Fir4exT5tCftvHlorgl0DtsAOQvm2qYCDFbDADMz
	i+SYBGtjIkfeiqWbmFm/jnI7AhEQ/z+W9D6jqrCyCTxOz9ri+uSe+fOwxFt+HRX9YNFR
	AHze3iq5xNFsjGx77ni84NoNonsKqwuJD9/zQ=
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;
	bh=kmv+mhDe+TmcsJDh40om1ZpkYc2YZWIDCOf22RF0h4c=;
	b=Y1q0CzdAJMMFMNZNrsSLPrwfTF1YeIW4oVKiTgNzekowdqc2xpQBK7WpWws8CivpjZ
	KVqd2TThvwPw/RrDbFDu2nG+XmREykFXpC5r0edw5OIG8o0fstm/78w4LTfTPT4nj4RP
	DQ2XV60GeUZuSGtNvl0npN351DycArW8i7IELef+bJpkGkrx1OCab7jLZRnuzJtv1ZVR
	BXzLcNkswLrtoKsTJzsoTUUUAGeD1T5x2l13JfLSuyGA84fPEoWyNuar8GT6tlq3E37D
	lM+q0qyXK90UfRUB190GpUoG63HcXZEiVin27PJOv6KWDhg/0T4x5e7FZw3x4YczXHyQ
	yFgw==
X-Gm-Message-State: AA+aEWYs5AcCdIophjFHjyh6inV/ALbj7yNppc8h+0PI6M3ex+3KUshS
	GpJbDozqzhPz5ArSb7dKp360u1K9di4i/GAgRMuumg==
X-Google-Smtp-Source: AFSGD/U9RRd6pERLJIObrxICWnGwl8cV1ma9vfZv2bamLcyoOdHHDxCBpsQboss8n62MMReoid/q5kurNa73hOFaerI=
X-Received: by 2002:a24:1490:: with SMTP id 138mr22996597itg.101.1544115441223;
	Thu, 06 Dec 2018 08:57:21 -0800 (PST)
MIME-Version: 1.0
References: <CAPg+sBhuPG-2GXc+Bp0yv5ywry2fk56LPLT4AY0Kcs+YEoz4FA@mail.gmail.com>
	<CAPg+sBiu0BjZEtz-t7m3M+TnAEDG_k1GKtxwkOKh6qrSezUO7g@mail.gmail.com>
In-Reply-To: <CAPg+sBiu0BjZEtz-t7m3M+TnAEDG_k1GKtxwkOKh6qrSezUO7g@mail.gmail.com>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Thu, 6 Dec 2018 11:57:09 -0500
Message-ID: <CAMZUoKkJdU0P_dVRvHn5zY6xUHYUptdK221ioQMp3FXZAerp3Q@mail.gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000005de8b7057c5d6491"
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: Sun, 09 Dec 2018 09:15:14 +0000
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: Thu, 06 Dec 2018 16:57:24 -0000

--0000000000005de8b7057c5d6491
Content-Type: text/plain; charset="UTF-8"

One more item to consider is "signature covers witness weight".

While signing the witness weight doesn't completely eliminate witness
malleability (of the kind that can cause grief for compact blocks), it does
eliminate the worst kind of witness malleability from the user's
perspective, the kind where malicious relay nodes increase the amount of
witness data and therefore reduce the overall fee-rate of the transaction.
Generally users should strive to construct their Bitcoin Scripts in such a
way that witness malleability isn't possible, but as you are probably
aware, this can be quite difficult to achieve as Scripts become more
complex and maybe isn't even possible for some complex Scripts.

Given the new fixed-sized signature of the Schnorr BIP, it becomes much
easier to compute the final witness weight prior to signing.  In complex
multi-party signing protocol, the final witness weight might not be known
at signing time for everyone involved, so the "signature covers witness
weight" ought to be optional.


On Tue, Nov 27, 2018 at 11:59 PM Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Mon, 19 Nov 2018 at 14:37, Pieter Wuille <pieter.wuille@gmail.com>
> wrote:
> > Here is a combined proposal:
> > * Three new sighash flags are added: SIGHASH_NOINPUT, SIGHASH_NOFEE, and
> SIGHASH_SCRIPTMASK.
> > * A new opcode OP_MASK is added, which acts as a NOP during execution.
> > * The sighash is computed like in BIP143, but:
> >   * If SIGHASH_SCRIPTMASK is present, for every OP_MASK in scriptCode
> the subsequent opcode/push is removed.
> >   * The scriptPubKey being spent is added to the sighash, unless
> SIGHASH_SCRIPTMASK is set.
> >   * The transaction fee is added to the sighash, unless SIGHASH_NOFEE is
> set.
> >   * hashPrevouts, hashSequence, and outpoint are set to null when
> SIGHASH_NOINPUT is set (like BIP118, but not for scriptCode).
>
> Thanks for all the input so far. Going over the suggestions and other
> ideas:
>
> * OP_MASK should be required to be followed by a push, as suggested by
> Anthony Towns. The alternative would permit substituting arbitrary
> opcodes for masked pushes, which is at least very hard to reason
> about. This would effectively turn it into a multi-byte OP_MASKEDPUSH
> opcode.
>
> * It's probably better to sign the amounts of all inputs, as suggested
> by Johnson Lau. As that would cause default sighashes to sign all
> input and output amounts, is there still a need to sign the tx fee
> explicitly? Or in other words, are there situations where changing the
> set of inputs or outputs after signing is desired, but the net
> difference between them cannot change? If not, that would remove the
> need for NOFEE.
>
> * Do we need to keep the rule that sequence values of other inputs are
> only signed with default sighash? It feels cleaner to always sign the
> sequence values of all inputs that are included in the sighash anyway
> (so all of them, unless ANYONECANPAY or NOINPUT, which would make it
> sign only the current input's sequence value). If NOINPUT also blanks
> the sequence values (as currently specified by BIP118), and all input
> amounts are signed, that would make amounts/sequence values always be
> treated identically.
>
> * If MASK implies NOINPUT, and NOINPUT implies ANYONECANPAY, the 3 of
> them can be encoded in just 2 bits using the
> PARTIALSCRIPT/KNOWNSCRIPT/KNOWNTX/ALL_INPUTS encoding Anthony Towns
> suggested.
>
> * Regarding the discussion about preventing signatures from being
> rebound to a different script(path)/checksig:
>   * With MAST there is indeed less need for this, but at least
> single-tree MAST constructions cannot replace all script branches (a
> script with 40 IF/THEN/ELSE constructions may have 2^40 different
> execution paths, for which computing a Merkle tree is intractable).
>   * Just signing the opcode position of the CHECKSIG operator isn't
> enough for all cases either. For example, you could have a complex
> nested set of branches that puts a number of pubkeys on the stack, and
> then a CHECKMULTISIG after the last ENDIF to verify all of them. In
> such a situation, if the same key can occur in multiple combinations,
> you still may want to prevent a signature generated for one
> combination from being rebindable to the same key in another
> combination. I believe that signing the opcode position plus the
> true/false condition of all previous(?) IF statements is probably
> sufficient to achieve that, but it would also introduce unnecessary
> complexity for signers in most cases (see next point).
>   * Thinking about signing code, adding these sort of execution trace
> commitments to the sighash means they need to know which checksig
> operator etc. they are signing for. I believe that in practice for
> example HW devices will just whatever position the wallet indicated,
> rather than verifying it corresponds with a particular intended code
> path. Preventing rebinding isn't very useful if an attacker can make
> you bind to the wrong thing regardless, so I'm not convinced this is
> even worth having by default.
>   * An alternative (not sure who suggested it) is to simply make every
> CHECKSIG sign the opcode position of the last executed CODESEPARATOR
> (and remove the earlier cut-of-scriptCode effect of CODESEPARATOR).
> This gives a simple (but somewhat limited) way for scripts that need
> to prevent certain kinds of cross-execution-trace rebinding.
>
> A few misc ideas:
> * (Taken from
> https://github.com/jl2012/bips/blob/sighash2/bip-sighash2.mediawiki)
> For a default sign-everything sighash, the sighash byte can be
> dropped.
> * For the commitments to the scriptPubKey and scriptCode, an
> intermediary hash should be used (so the data included in the sighash
> includes a hash of those, rather than the script directly). This
> prevents a blow up in hashing time for large scripts with many
> different sighash types in its signatures.
> * When masking the scriptCode, the push opcode immediately following
> OP_MASKEDPUSH can be replaced by OP_VERIF (which will never collide
> with any real script, as OP_VERIF makes a script invalid even when
> occurring in an unexecuted branch).
> * Sighashes (and really all new hashes that are introduced) should be
> prefixed with a fixed 64-byte array as "tag", chosen to not collide
> with any existing use of SHA256 in Bitcoin, to prevent signatures from
> being re-interpretable as something else. Picking 64 bytes as tag size
> means it can be efficiently implemented as just a modified SHA256 IV.
>
> So a combined proposal:
> * All existing sighash flags, plus NOINPUT and MASK
> (ANYONECANPAY/NOINPUT/MASK are encoded in 2 bits).
> * A new opcode called OP_MASKEDPUSH, whose only runtime behaviour is
> failing if not immediately followed by a push, or when appearing as
> last opcode in the script.
> * Signatures are 64 plus an optional sighash byte. A missing sighash
> byte implies ALL, and ALL cannot be specified explicitly.
> * The sighash is computed from the following:
>   * A 64-byte constant tag
>   * Data about the spending transaction:
>     * The transaction version number
>     * The hash of txins' prevouts+amounts+sequences (or nothing if
> ANYONECANPAY)
>     * The hash of all txouts (or just the corresponding txout if
> SINGLE; nothing if NONE)
>     * The transaction locktime
>   * Data about the output being spent:
>     * The prevout (or nothing if NOINPUT)
>     * The amount
>     * The sequence number
>     * The hash of the scriptPubKey (or nothing if MASK)
>   * Data about the script being executed:
>     * The hash of the scriptCode (after masking out, if MASK is set)
>     * The opcode number of the last executed OP_CODESEPARATOR (or
> 0xFFFFFFFF if none)
>   * The sighash mode
>
> Cheers,
>
> --
> Pieter
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--0000000000005de8b7057c5d6491
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>One more item to consider is &quot;signature covers w=
itness weight&quot;.</div><div><br></div><div>While signing the witness wei=
ght doesn&#39;t completely eliminate witness malleability (of the kind that=
 can cause grief for compact blocks), it does eliminate the worst kind of w=
itness malleability from the user&#39;s perspective, the kind where malicio=
us relay nodes increase the amount of witness data and therefore reduce the=
 overall fee-rate of the transaction.=C2=A0 Generally users should strive t=
o construct their Bitcoin Scripts in such a way that witness malleability i=
sn&#39;t possible, but as you are probably aware, this can be quite difficu=
lt to achieve as Scripts become more complex and maybe isn&#39;t even possi=
ble for some complex Scripts.</div><div><br></div><div>Given the new fixed-=
sized signature of the Schnorr BIP, it becomes much easier to compute the f=
inal witness weight prior to signing.=C2=A0 In complex multi-party signing =
protocol, the final witness weight might not be known at signing time for e=
veryone involved, so the &quot;signature covers witness weight&quot; ought =
to be optional.<br></div><br></div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr">On Tue, Nov 27, 2018 at 11:59 PM Pieter Wuille via bitcoin-dev &lt=
;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists=
.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
>On Mon, 19 Nov 2018 at 14:37, Pieter Wuille &lt;<a href=3D"mailto:pieter.w=
uille@gmail.com" target=3D"_blank">pieter.wuille@gmail.com</a>&gt; wrote:<b=
r>
&gt; Here is a combined proposal:<br>
&gt; * Three new sighash flags are added: SIGHASH_NOINPUT, SIGHASH_NOFEE, a=
nd SIGHASH_SCRIPTMASK.<br>
&gt; * A new opcode OP_MASK is added, which acts as a NOP during execution.=
<br>
&gt; * The sighash is computed like in BIP143, but:<br>
&gt;=C2=A0 =C2=A0* If SIGHASH_SCRIPTMASK is present, for every OP_MASK in s=
criptCode the subsequent opcode/push is removed.<br>
&gt;=C2=A0 =C2=A0* The scriptPubKey being spent is added to the sighash, un=
less SIGHASH_SCRIPTMASK is set.<br>
&gt;=C2=A0 =C2=A0* The transaction fee is added to the sighash, unless SIGH=
ASH_NOFEE is set.<br>
&gt;=C2=A0 =C2=A0* hashPrevouts, hashSequence, and outpoint are set to null=
 when SIGHASH_NOINPUT is set (like BIP118, but not for scriptCode).<br>
<br>
Thanks for all the input so far. Going over the suggestions and other ideas=
:<br>
<br>
* OP_MASK should be required to be followed by a push, as suggested by<br>
Anthony Towns. The alternative would permit substituting arbitrary<br>
opcodes for masked pushes, which is at least very hard to reason<br>
about. This would effectively turn it into a multi-byte OP_MASKEDPUSH<br>
opcode.<br>
<br>
* It&#39;s probably better to sign the amounts of all inputs, as suggested<=
br>
by Johnson Lau. As that would cause default sighashes to sign all<br>
input and output amounts, is there still a need to sign the tx fee<br>
explicitly? Or in other words, are there situations where changing the<br>
set of inputs or outputs after signing is desired, but the net<br>
difference between them cannot change? If not, that would remove the<br>
need for NOFEE.<br>
<br>
* Do we need to keep the rule that sequence values of other inputs are<br>
only signed with default sighash? It feels cleaner to always sign the<br>
sequence values of all inputs that are included in the sighash anyway<br>
(so all of them, unless ANYONECANPAY or NOINPUT, which would make it<br>
sign only the current input&#39;s sequence value). If NOINPUT also blanks<b=
r>
the sequence values (as currently specified by BIP118), and all input<br>
amounts are signed, that would make amounts/sequence values always be<br>
treated identically.<br>
<br>
* If MASK implies NOINPUT, and NOINPUT implies ANYONECANPAY, the 3 of<br>
them can be encoded in just 2 bits using the<br>
PARTIALSCRIPT/KNOWNSCRIPT/KNOWNTX/ALL_INPUTS encoding Anthony Towns<br>
suggested.<br>
<br>
* Regarding the discussion about preventing signatures from being<br>
rebound to a different script(path)/checksig:<br>
=C2=A0 * With MAST there is indeed less need for this, but at least<br>
single-tree MAST constructions cannot replace all script branches (a<br>
script with 40 IF/THEN/ELSE constructions may have 2^40 different<br>
execution paths, for which computing a Merkle tree is intractable).<br>
=C2=A0 * Just signing the opcode position of the CHECKSIG operator isn&#39;=
t<br>
enough for all cases either. For example, you could have a complex<br>
nested set of branches that puts a number of pubkeys on the stack, and<br>
then a CHECKMULTISIG after the last ENDIF to verify all of them. In<br>
such a situation, if the same key can occur in multiple combinations,<br>
you still may want to prevent a signature generated for one<br>
combination from being rebindable to the same key in another<br>
combination. I believe that signing the opcode position plus the<br>
true/false condition of all previous(?) IF statements is probably<br>
sufficient to achieve that, but it would also introduce unnecessary<br>
complexity for signers in most cases (see next point).<br>
=C2=A0 * Thinking about signing code, adding these sort of execution trace<=
br>
commitments to the sighash means they need to know which checksig<br>
operator etc. they are signing for. I believe that in practice for<br>
example HW devices will just whatever position the wallet indicated,<br>
rather than verifying it corresponds with a particular intended code<br>
path. Preventing rebinding isn&#39;t very useful if an attacker can make<br=
>
you bind to the wrong thing regardless, so I&#39;m not convinced this is<br=
>
even worth having by default.<br>
=C2=A0 * An alternative (not sure who suggested it) is to simply make every=
<br>
CHECKSIG sign the opcode position of the last executed CODESEPARATOR<br>
(and remove the earlier cut-of-scriptCode effect of CODESEPARATOR).<br>
This gives a simple (but somewhat limited) way for scripts that need<br>
to prevent certain kinds of cross-execution-trace rebinding.<br>
<br>
A few misc ideas:<br>
* (Taken from <a href=3D"https://github.com/jl2012/bips/blob/sighash2/bip-s=
ighash2.mediawiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/=
jl2012/bips/blob/sighash2/bip-sighash2.mediawiki</a>)<br>
For a default sign-everything sighash, the sighash byte can be<br>
dropped.<br>
* For the commitments to the scriptPubKey and scriptCode, an<br>
intermediary hash should be used (so the data included in the sighash<br>
includes a hash of those, rather than the script directly). This<br>
prevents a blow up in hashing time for large scripts with many<br>
different sighash types in its signatures.<br>
* When masking the scriptCode, the push opcode immediately following<br>
OP_MASKEDPUSH can be replaced by OP_VERIF (which will never collide<br>
with any real script, as OP_VERIF makes a script invalid even when<br>
occurring in an unexecuted branch).<br>
* Sighashes (and really all new hashes that are introduced) should be<br>
prefixed with a fixed 64-byte array as &quot;tag&quot;, chosen to not colli=
de<br>
with any existing use of SHA256 in Bitcoin, to prevent signatures from<br>
being re-interpretable as something else. Picking 64 bytes as tag size<br>
means it can be efficiently implemented as just a modified SHA256 IV.<br>
<br>
So a combined proposal:<br>
* All existing sighash flags, plus NOINPUT and MASK<br>
(ANYONECANPAY/NOINPUT/MASK are encoded in 2 bits).<br>
* A new opcode called OP_MASKEDPUSH, whose only runtime behaviour is<br>
failing if not immediately followed by a push, or when appearing as<br>
last opcode in the script.<br>
* Signatures are 64 plus an optional sighash byte. A missing sighash<br>
byte implies ALL, and ALL cannot be specified explicitly.<br>
* The sighash is computed from the following:<br>
=C2=A0 * A 64-byte constant tag<br>
=C2=A0 * Data about the spending transaction:<br>
=C2=A0 =C2=A0 * The transaction version number<br>
=C2=A0 =C2=A0 * The hash of txins&#39; prevouts+amounts+sequences (or nothi=
ng if ANYONECANPAY)<br>
=C2=A0 =C2=A0 * The hash of all txouts (or just the corresponding txout if<=
br>
SINGLE; nothing if NONE)<br>
=C2=A0 =C2=A0 * The transaction locktime<br>
=C2=A0 * Data about the output being spent:<br>
=C2=A0 =C2=A0 * The prevout (or nothing if NOINPUT)<br>
=C2=A0 =C2=A0 * The amount<br>
=C2=A0 =C2=A0 * The sequence number<br>
=C2=A0 =C2=A0 * The hash of the scriptPubKey (or nothing if MASK)<br>
=C2=A0 * Data about the script being executed:<br>
=C2=A0 =C2=A0 * The hash of the scriptCode (after masking out, if MASK is s=
et)<br>
=C2=A0 =C2=A0 * The opcode number of the last executed OP_CODESEPARATOR (or=
<br>
0xFFFFFFFF if none)<br>
=C2=A0 * The sighash mode<br>
<br>
Cheers,<br>
<br>
-- <br>
Pieter<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--0000000000005de8b7057c5d6491--