path: root/e2/a061a79a5b3e087d27a72c5fac5a00d323a475

Return-Path: <andrew.kozlik@satoshilabs.com>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 32080C0175
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  4 May 2020 15:48:14 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by hemlock.osuosl.org (Postfix) with ESMTP id 1F8A288515
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  4 May 2020 15:48:14 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id FyB5bDe6iZlm
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  4 May 2020 15:48:13 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ej1-f66.google.com (mail-ej1-f66.google.com
 [209.85.218.66])
 by hemlock.osuosl.org (Postfix) with ESMTPS id CB8EC88184
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  4 May 2020 15:48:12 +0000 (UTC)
Received: by mail-ej1-f66.google.com with SMTP id re23so14290959ejb.4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 04 May 2020 08:48:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=satoshilabs.com; s=google;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=ekNer+ShfbG0J3YkqnC4PlKz2q3kyuLn4iQxymJAtQk=;
 b=ISMkE/oihhAxfwVxnoXpIJr+7zcThV4NDZf6AQWop6D7MPnOrqsednwKWFcR1+EneV
 1eeu5ZYlSDlibe9f6mkutdxhAije1aV24Id0RtejPt/ZoKKArhNDlrAe2USNRxpTbcKr
 xPeeQv66H8dO2E9cWHHv7miq1Ks0z+TekFvPjU8d9ZyfTdhjje4RMNddCQi7MYjQV0/d
 AK1C9fejLLCJ7aIfBd6wPo/sNDn2FMzrL7qF0T9myhUVpIZ6BmpWfVj+ybeVmd4B7cB/
 Y/6aMlBA7q6Ix61QOzHs0bPb+baAuuFK9dN6EA7NYlrhFOkoCxrGhIIV3GfpYrT7XKwq
 iUTw==
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=ekNer+ShfbG0J3YkqnC4PlKz2q3kyuLn4iQxymJAtQk=;
 b=Epnoi/FaXD+T6xmZA/RGE6EPdBfAOiQdJC9Xwb+pa+rRgSucwQEj5cCqKXcrfDUxlV
 d3kqAm2DNds32biAb99eQ7DhtwSjVWfPjGyAd/jguZL5WNQwyLG/tilesRbaHFhzdK+/
 zx4MICcTpdE5qXK0Wt9CYMZHTlsn+q2ePS1L0cKLSJmTUT1lurQClVrFT54bcfiAF54Q
 noPBsfVyhYEVdzpmy6YTPfiRgLDxgv+KpMUpF+eKjmglXEoU9eKsrQHXaHFPTFzmDKvH
 311S8+2DMJqEFt1CLqK2o8ikgnA3leIfZmKunyUFK/mmtug2O7kYrypvz9VMEQrICR5K
 I3Vg==
X-Gm-Message-State: AGi0PuZjxAoCZXAw7J87rQZf8KFGlNoj42QY1ouopl7u0DJYX93HPkGl
 Hd9CRqAUVakAuW8l16mVETyMjpYTaYQEleDSy92l9w==
X-Google-Smtp-Source: APiQypKJoGHqxzaXdCESlHfs74fa7XqH7S6aKUVAJ1uS5enSEFaeJuRD5FhLCYQgXo03BSiCDGy7NBF044GudxHkBqk=
X-Received: by 2002:a17:906:f295:: with SMTP id
 gu21mr15846372ejb.83.1588607291188; 
 Mon, 04 May 2020 08:48:11 -0700 (PDT)
MIME-Version: 1.0
References: <CACvH2e=3s2kZWnytMySTv8U4pny3i0rEWas7NxzLxf5J7BewTg@mail.gmail.com>
 <CAMZUoKm9sogtKS0YqOz8JNNbiiwBdkPbdEvf67yzcJr1BZ7_wA@mail.gmail.com>
 <20200502142602.rj7q2m32ew6trh6u@erisian.com.au>
 <CAMZUoKmrD78naPBcfGsfr_OxyYiWM+G47sWtpNGP+u-9r4MjXA@mail.gmail.com>
In-Reply-To: <CAMZUoKmrD78naPBcfGsfr_OxyYiWM+G47sWtpNGP+u-9r4MjXA@mail.gmail.com>
From: Andrew Kozlik <andrew.kozlik@satoshilabs.com>
Date: Mon, 4 May 2020 17:48:00 +0200
Message-ID: <CACvH2e=sxeJ22v6zFEftiNAyJfd5vEaqew4rTVQdhaSnnM0gSw@mail.gmail.com>
To: "Russell O'Connor" <roconnor@blockstream.com>
Content-Type: multipart/alternative; boundary="0000000000004785d605a4d47580"
X-Mailman-Approved-At: Mon, 04 May 2020 15:50:53 +0000
Cc: jonasd.nick@gmail.com,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Pieter Wuille <pieter.wuille@gmail.com>
Subject: Re: [bitcoin-dev] BIP-341: Committing to all scriptPubKeys in the
 signature message
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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: Mon, 04 May 2020 15:48:14 -0000

--0000000000004785d605a4d47580
Content-Type: text/plain; charset="UTF-8"

>
> A side effect of this proposal is it would seem to make it not possible to
> produce a signature for a transaction without having access to the inputs.
> This is limiting for a number of cases where you don't care about that
> data. There are a litany of use cases where you don't want to have
> SIGHASH_ALL behavior, and having to sign the scriptpubkeys breaks that. So
> at the very least it should respect other flags.
>

I agree, sha_scriptPubKeys should be included only if hash_type does not
match SIGHASH_ANYONECANPAY. I am also sympathetic to aj's idea of making
the scriptPubKey field dependent on hash_type matching SIGHASH_ANYONECANPAY.

I also don't really understand the exact attack. So you submit a
> transaction to the wallet asking them to sign input 10. They sign. They've
> committed to the signature being bound to the specific COutpoint and input
> index, so I don't see how they wouldn't be required to sign a second
> signature with the other output too? Is there an attack you can describe
> end-to-end relying on this behavior?
>

For example, in a CoinJoin transaction the attacker can construct a
transaction with two inputs (in1, in2) of identical value and two outputs
of identical value, one belonging to the user (user_out) and another
belonging to the attacker (attacker_out). If such a transaction is sent to
the hardware wallet twice with in1 marked as external the first time and
in2 marked as external the second time, then the hardware wallet will
display two signing requests to the user with spending amounts of in2 -
user_out and in1 - user_out respectively. The user will think that they are
signing two different CoinJoin transactions, while in reality they are
signing two different inputs to a single transaction and sending half of
the amount to the attacker.

As an alternative proposal, I think you can just make a separate BIP for
> some new sigash flags that can be reviewed separately from taproot. There's
> a lot of value in investing in figuring out more granular controls over
> what the signature hash is you sign, which may have some exciting
> contracting implications!
>

The proposal of adding sha_scriptPubKeys is just an optimization which is
not intended to change what the signature message is committing to. Thus I
don't see it as warranting a new sigash flag.

Alternatively, there's the scheme described in the email you linked by Greg
> Saunders (with the scheme co-attributed to Andrew Poelstra), which seems
> reasonable to me.[1]  It's only downside (AFAICT) is that it requires an
> extra one-way communication from a signing device to a coordinator.  For a
> true offline signer, that can be annoying, but for an automated hardware
> wallet participating in coinjoins or LN, that doesn't seem too burdensome
> to me.
>

Yes, I see this as the correct direction forward. Whatever the exact format
of the ownership proof will be, the proof will need to be signed by the
owner of the UTXO using BIP-0322 or something along those lines. So the
scriptPubKey is needed to verify that signature.

Cheers,
Andrew Kozlik

On Sat, May 2, 2020 at 11:16 PM Russell O'Connor <roconnor@blockstream.com>
wrote:

> On Sat, May 2, 2020 at 10:26 AM Anthony Towns <aj@erisian.com.au> wrote:
>
>>
>> except that we'd arguably still be missing:
>>
>>     is this a coinbase output? (Coin.fCoinBase)
>>     what was the height of the coin? (Coin.nHeight)
>>
>> Maybe committing to the coinbase flag would have some use, but committing
>> to the height would make it hard to chain unconfirmed spends, so at
>> least that part doesn't seem worth adding.
>>
>
> To add to this point, the height of the coin is something that is *not*
> currently covered by any signature mode and including it would constitute a
> change of an entirely different  caliber; a change that I would strongly
> caution against for your above reason and more.
>
> The coinbase output flag is currently covered by the signature as the
> outpoint hash has the required information (its prevout index of 0xFFFFFFFF
> is only legal in a coinbase transaction).  While I'm not particularly
> enthusiastic about making it easier to distinguish coinbase outputs from
> other outputs, and I worry a little about alternative designs for
> implementing the Bitcoin protocol where this information is not so readily
> available, I suppose I won't really oppose adding it.  However, I don't
> think anyone is seriously proposing it.
>
>    -
>
>

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">A side e=
ffect of this proposal is it would seem to make it not possible to produce =
a signature for a transaction without having access to the inputs. This is =
limiting for a number of cases where you don&#39;t care about that data. Th=
ere are a litany of use cases where you don&#39;t want to have SIGHASH_ALL =
behavior, and having to sign the scriptpubkeys breaks that. So at the very =
least it should respect other flags.<br></blockquote><br>I agree, sha_scrip=
tPubKeys should be included only if hash_type does not match SIGHASH_ANYONE=
CANPAY. I am also sympathetic to aj&#39;s idea of making the scriptPubKey f=
ield dependent on hash_type matching SIGHASH_ANYONECANPAY.<br><br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex">I also don&#39;t really understand=
 the exact attack. So you submit a transaction to the wallet asking them to=
 sign input 10. They sign. They&#39;ve committed to the signature being bou=
nd to the specific COutpoint and input index, so I don&#39;t see how they w=
ouldn&#39;t be required to sign a second signature with the other output to=
o? Is there an attack you can describe end-to-end relying on this behavior?=
<br></blockquote><br>For example, in a CoinJoin transaction the attacker ca=
n construct a transaction with two inputs (in1, in2) of identical value and=
 two outputs of identical value, one belonging to the user (user_out) and a=
nother belonging to the attacker (attacker_out). If such a transaction is s=
ent to the hardware wallet twice with in1 marked as external the first time=
 and in2 marked as external the second time, then the hardware wallet will =
display two signing requests to the user with spending amounts of in2 - use=
r_out and in1 - user_out respectively. The user will think that they are si=
gning two different CoinJoin transactions, while in reality they are signin=
g two different inputs to a single transaction and sending half of the amou=
nt to the attacker.<br><br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
">As an alternative proposal, I think you can just make a separate BIP for =
some new sigash flags that can be reviewed separately from taproot. There&#=
39;s a lot of value in investing in figuring out more granular controls ove=
r what the signature hash is you sign, which may have some exciting contrac=
ting implications!<br></blockquote><br>The proposal of adding sha_scriptPub=
Keys is just an optimization which is not intended to change what the signa=
ture message is committing to. Thus I don&#39;t see it as warranting a new =
sigash flag.<br><br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Alter=
natively, there&#39;s the scheme described in the email you linked by Greg =
Saunders (with the scheme co-attributed to Andrew Poelstra), which seems re=
asonable to me.[1] =C2=A0It&#39;s only downside (AFAICT) is that it require=
s an extra one-way communication from a signing device to a coordinator.=C2=
=A0 For a true offline signer, that can be annoying, but for an automated h=
ardware wallet participating in coinjoins or LN, that doesn&#39;t seem too =
burdensome to me.<br></blockquote><br><div>Yes, I see this as the correct d=
irection forward. Whatever the exact format of the ownership proof will be,=
 the proof will need to be signed by the owner of the UTXO using BIP-0322 o=
r something along those lines. So the scriptPubKey is needed to verify that=
 signature.</div><div><br></div><div>Cheers,</div><div>Andrew Kozlik<br></d=
iv></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_att=
r">On Sat, May 2, 2020 at 11:16 PM Russell O&#39;Connor &lt;<a href=3D"mail=
to:roconnor@blockstream.com">roconnor@blockstream.com</a>&gt; wrote:<br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div =
class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, May 2, =
2020 at 10:26 AM Anthony Towns &lt;<a href=3D"mailto:aj@erisian.com.au" tar=
get=3D"_blank">aj@erisian.com.au</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><br>
except that we&#39;d arguably still be missing:<br>
<br>
=C2=A0 =C2=A0 is this a coinbase output? (Coin.fCoinBase)<br>
=C2=A0 =C2=A0 what was the height of the coin? (Coin.nHeight)<br>
<br>
Maybe committing to the coinbase flag would have some use, but committing<b=
r>
to the height would make it hard to chain unconfirmed spends, so at<br>
least that part doesn&#39;t seem worth adding.<br></blockquote><div><br></d=
iv><div>To add to this point, the height of the coin is something that is *=
not* currently covered by any signature mode and including it would constit=
ute a change of an entirely different=C2=A0 caliber; a change that I would =
strongly caution against for your above reason and more.</div><div><br></di=
v><div>The coinbase output flag is currently covered by the signature as th=
e outpoint hash has the required information (its prevout index of 0xFFFFFF=
FF is only legal in a coinbase transaction).=C2=A0 While I&#39;m not partic=
ularly enthusiastic about making it easier to distinguish coinbase outputs =
from other outputs, and I worry a little about alternative designs for impl=
ementing the Bitcoin protocol where this information is not so readily avai=
lable, I suppose I won&#39;t really oppose adding it.=C2=A0 However, I don&=
#39;t think anyone is seriously proposing it.<br><ul><li></li></ul></div></=
div></div>
</blockquote></div>

--0000000000004785d605a4d47580--