path: root/85/92ae85d1b71843e4ea1bfdce593543a9dffd55

Return-Path: <gsanders87@gmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 77A33C016F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  1 May 2020 12:26:07 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by whitealder.osuosl.org (Postfix) with ESMTP id 65A6F88C91
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  1 May 2020 12:26:07 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id W1ltsf1-voBl
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  1 May 2020 12:26:06 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-wr1-f51.google.com (mail-wr1-f51.google.com
 [209.85.221.51])
 by whitealder.osuosl.org (Postfix) with ESMTPS id 3A11C88C98
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  1 May 2020 12:26:06 +0000 (UTC)
Received: by mail-wr1-f51.google.com with SMTP id o27so6038372wra.12
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 01 May 2020 05:26:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=UpyhgpTnz1rNjyPStFL6ir8iKbnIfYRGb3S39QqvEBo=;
 b=YEzGQe2QECH2Db0aJFJ0UnXC6KOC6KVNLzA3lT+5+eASe2zgMyRpEFEFwAvLiuAs+1
 Yg/M5M4V1KPSRpoa+1UooeKMnS6zm+5HOtM/7ofdERZiXH1/vUDigb/QL2CvG7bJHauF
 n0KbMCR2vwbHpta6xIwIpVSdcwi5FNSM9iopG27OLhh6zlOl1nHGc/aJ14seRfVPv9rg
 bC/jgiu19dkulhVzPZrrhQuBZLyeUvl3dyGNt4YbbsUroSC+SxrNYW8+NytDwLVl9A1J
 p3W0+fP7/bf3VtD8WnBt86C/H6V/cKwDXWxzON5hbh+awRIPqETwrGjwK+g2z/11QJQn
 ualA==
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=UpyhgpTnz1rNjyPStFL6ir8iKbnIfYRGb3S39QqvEBo=;
 b=T7IDg8CLx/M2fZyZDBxX6skBqtsTp3sy5LkwYK7ghFbr7Mv7kOKH9SfSLG1abWkeAT
 uz+9AT3FlD18zWnVlyueKh9ua3hk5BtqR1emvgJZuLsesjXD6xKWTYGBqMEFM0psSGqz
 V6XnflgmRuXBPOwjR3a46GvkqR3cmP3KHW4uoE99sSdkc/M6iSsBQCMWDtJ+XxPhaQhZ
 kL39YWyYDpx34kZf+FTNxXOUbU/DiHXMg80pjBeVWN70zfeVsDQmwzBlCudUG9YvM5rj
 2q4ekeBYkSCeKFNmCepY+DNkzZTCS032aMtiuCLB2kzqEPBOsgva7P5Lxxaj67lfkMNo
 qfsA==
X-Gm-Message-State: AGi0Pubgk5faacJ8SAERXbAa79WWw2HSDzAt3qiN3PVykKoqmMKUYhwD
 EmjAgkMdQnxxugAXQF+6hCaSl22f+56jOLnSfgI=
X-Google-Smtp-Source: APiQypLPejuiAdJBgRXwqa6iojfuJ/F185BxZqlsr7muN5jma9vb0jDIeXIfLqyaPpiEvA44U5vlSxRmymcws91Y5jA=
X-Received: by 2002:adf:dd07:: with SMTP id a7mr3843546wrm.349.1588335964670; 
 Fri, 01 May 2020 05:26:04 -0700 (PDT)
MIME-Version: 1.0
References: <CACvH2e=3s2kZWnytMySTv8U4pny3i0rEWas7NxzLxf5J7BewTg@mail.gmail.com>
 <CAMZUoKm9sogtKS0YqOz8JNNbiiwBdkPbdEvf67yzcJr1BZ7_wA@mail.gmail.com>
In-Reply-To: <CAMZUoKm9sogtKS0YqOz8JNNbiiwBdkPbdEvf67yzcJr1BZ7_wA@mail.gmail.com>
From: Greg Sanders <gsanders87@gmail.com>
Date: Fri, 1 May 2020 08:25:53 -0400
Message-ID: <CAB3F3Dt-HT8vX-eENE5B5Oz9Z6+he6FZWwNCq3MNExg0KA7zNw@mail.gmail.com>
To: "Russell O'Connor" <roconnor@blockstream.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000f5523a05a495484e"
Cc: jonasd.nick@gmail.com, 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: Fri, 01 May 2020 12:26:07 -0000

--000000000000f5523a05a495484e
Content-Type: text/plain; charset="UTF-8"

For what it's worth this measure had been discussed as a lightweight way of
informing offline signers if inputs were segwit or not for malleability
analysis reasons. So there's at least a couple direct use-cases it seems.

On Fri, May 1, 2020, 8:23 AM Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> While I'm not entirely convinced yet that accertaining non-ownership of an
> input is a robust method of solving the problem here, I also see little
> reason not to amend BIP-341 as proposed. The ScriptPubKeys in question is
> already indirectly covered through the outpoints, so it is just a matter of
> optimization.  Furthermore in the consensus code, the ScriptPubKeys are
> part of the UTXO data set, and it is already being retrieved as part of the
> transaction checking process, so it is readily available.
>
> I'm not sure how much my opinion on the topic matters, but I did include
> this kind of functionality in my design for Simplicity on Elements, and I
> have been leaning towards adding this kind of functionality in my Bitcoin
> demo application of Simplicity.
>
> Regarding specifics, I personally think it would be better to keep the
> hashes of the ScriptPubKeys separate from the hashes of the input values.
> This way anyone only interested in input values does not need to wade
> through what are, in principle, arbitrarily long ScriptPubKeys in order to
> check the input values (which each fixed size).  To that end, I would also
> (and independently) propose separating the hashing of the output values
> from the output ScriptPubKeys in `sha_outputs` so again, applications
> interested only in summing the values of the outputs (for instance to
> compute fees) do not have to wade through those arbitrarily long
> ScriptPubKeys in the outputs.
>
> On Thu, Apr 30, 2020 at 4:22 AM Andrew Kozlik via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi everyone,
>>
>> In the current draft of BIP-0341 [1] the signature message commits to the
>> scriptPubKey of the output being spent by the input. I propose that the
>> signature message should commit to the scriptPubKeys of *all* transaction
>> inputs.
>>
>> In certain applications like CoinJoin, a wallet has to deal with
>> transactions containing external inputs. To calculate the actual amount
>> that the user is spending, the wallet needs to reliably determine for each
>> input whether it belongs to the wallet or not. Without such a mechanism an
>> adversary can fool the wallet into displaying incorrect information about
>> the amount being spent, which can result in theft of user funds [2].
>>
>> In order to ascertain non-ownership of an input which is claimed to be
>> external, the wallet needs the scriptPubKey of the previous output spent by
>> this input. It must acquire the full transaction being spent and verify its
>> hash against that which is given in the outpoint. This is an obstacle in
>> the implementation of lightweight air-gapped wallets and hardware wallets
>> in general. If the signature message would commit to the scriptPubKeys of
>> all transaction inputs, then the wallet would only need to acquire the
>> scriptPubKey of the output being spent without having to acquire and verify
>> the hash of the entire previous transaction. If an attacker would provide
>> an incorrect scriptPubKey, then that would cause the wallet to generate an
>> invalid signature message.
>>
>> Note that committing only to the scriptPubKey of the output being spent
>> is insufficient for this application, because the scriptPubKeys which are
>> needed to ascertain non-ownership of external inputs are precisely the ones
>> that would not be included in any of the signature messages produced by the
>> wallet.
>>
>> The obvious way to implement this is to add another hash to the signature
>> message:
>> sha_scriptPubKeys (32): the SHA256 of the serialization of all
>> scriptPubKeys of the previous outputs spent by this transaction.
>>
>> Cheers,
>> Andrew Kozlik
>>
>> [1]
>> https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#common-signature-message
>> [2]
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-August/014843.html
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"auto">For what=C2=A0it&#39;s worth this measure had been discus=
sed as a lightweight way of informing offline signers if inputs were segwit=
 or not for malleability analysis reasons. So there&#39;s at least a couple=
 direct use-cases it seems.=C2=A0</div><br><div class=3D"gmail_quote"><div =
dir=3D"ltr" class=3D"gmail_attr">On Fri, May 1, 2020, 8:23 AM Russell O&#39=
;Connor via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfounda=
tion.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>While I&#39;m not entirel=
y convinced yet that accertaining non-ownership of an input is a robust met=
hod of solving the problem here, I also see little reason not to amend BIP-=
341 as proposed. The ScriptPubKeys in question is already indirectly covere=
d through the outpoints, so it is just a matter of optimization.=C2=A0 Furt=
hermore in the consensus code, the  ScriptPubKeys are part of the UTXO data=
 set, and it is already being retrieved as part of the transaction checking=
 process, so it is readily available.</div><div><br></div><div>I&#39;m not =
sure how much my opinion on the topic matters, but I did include this kind =
of functionality in my design for Simplicity on Elements, and I have been l=
eaning towards adding this kind of functionality in my Bitcoin demo applica=
tion of Simplicity.</div><div><br></div><div>Regarding specifics, I persona=
lly think it would be better to keep the hashes of the ScriptPubKeys separa=
te from the hashes of the input values.=C2=A0 This way anyone only interest=
ed in input values does not need to wade through what are, in principle, ar=
bitrarily long ScriptPubKeys in order to check the input values (which each=
 fixed size).=C2=A0 To that end, I would also (and independently) propose s=
eparating the hashing of the output values from the output ScriptPubKeys in=
 `sha_outputs` so again, applications interested only in summing the values=
 of the outputs (for instance to compute fees) do not have to wade through =
those arbitrarily long ScriptPubKeys in the outputs.<br></div><br><div clas=
s=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Apr 30, 202=
0 at 4:22 AM Andrew Kozlik via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-de=
v@lists.linuxfoundation.org" target=3D"_blank" rel=3D"noreferrer">bitcoin-d=
ev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex"><div dir=3D"ltr">Hi everyone,<br><br>In the cur=
rent draft of BIP-0341 [1] the signature message commits to the scriptPubKe=
y of the output being spent by the input. I propose that the signature mess=
age should commit to the scriptPubKeys of *all* transaction inputs.<br><br>=
In certain applications like CoinJoin, a wallet has to deal with transactio=
ns containing external inputs. To calculate the actual amount that the user=
 is spending, the wallet needs to reliably determine for each input whether=
 it belongs to the wallet or not. Without such a mechanism an adversary can=
 fool the wallet into displaying incorrect information about the amount bei=
ng spent, which can result in theft of user funds [2].<br><br>In order to a=
scertain non-ownership of an input which is claimed to be external, the wal=
let needs the scriptPubKey of the previous output spent by this input. It m=
ust acquire the full transaction being spent and verify its hash against th=
at which is given in the outpoint. This is an obstacle in the implementatio=
n of lightweight air-gapped wallets and hardware wallets in general. If the=
 signature message would commit to the scriptPubKeys of all transaction inp=
uts, then the wallet would only need to acquire the scriptPubKey of the out=
put being spent without having to acquire and verify the hash of the entire=
 previous transaction. If an attacker would provide an incorrect scriptPubK=
ey, then that would cause the wallet to generate an invalid signature messa=
ge.<br><div><br></div><div>Note that committing only to the scriptPubKey of=
 the output being spent is insufficient for this application, because the s=
criptPubKeys which are needed to ascertain non-ownership of external inputs=
 are precisely the ones that would not be included in any of the signature =
messages produced by the wallet.</div><div><br></div>The obvious way to imp=
lement this is to add another hash to the signature message:<br>sha_scriptP=
ubKeys (32): the SHA256 of the serialization of all scriptPubKeys of the pr=
evious outputs spent by this transaction.<br><div><br></div><div>Cheers,<br=
></div><div>Andrew Kozlik</div><div><br></div>[1] <a href=3D"https://github=
.com/bitcoin/bips/blob/master/bip-0341.mediawiki#common-signature-message" =
target=3D"_blank" rel=3D"noreferrer">https://github.com/bitcoin/bips/blob/m=
aster/bip-0341.mediawiki#common-signature-message</a><br>[2] <a href=3D"htt=
ps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-August/014843.htm=
l" target=3D"_blank" rel=3D"noreferrer">https://lists.linuxfoundation.org/p=
ipermail/bitcoin-dev/2017-August/014843.html</a><br></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000f5523a05a495484e--