MIME-Version: 1.0
References: <CACvH2e=3s2kZWnytMySTv8U4pny3i0rEWas7NxzLxf5J7BewTg@mail.gmail.com>
 <CAD5xwhgo0YfpOcKoBYSFYrx8bOT2RNDzM0+JiLqhZaLi_0C5RA@mail.gmail.com>
In-Reply-To: <CAD5xwhgo0YfpOcKoBYSFYrx8bOT2RNDzM0+JiLqhZaLi_0C5RA@mail.gmail.com>
From: Andrew Kozlik <andrew.kozlik@satoshilabs.com>
Date: Fri, 1 May 2020 10:48:41 +0200
Message-ID: <CACvH2e=_ShBk6cJq8Tow3+T=9_ZSbDy2npEGLfkXCj3QQnLxtA@mail.gmail.com>
To: Jeremy <jlrubin@mit.edu>
Content-Type: multipart/alternative; boundary="00000000000032446b05a49240de"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP-341: Committing to all scriptPubKeys in the
 signature message
Precedence: list

--00000000000032446b05a49240de
Content-Type: text/plain; charset="UTF-8"

Hi Jeremy,

What you are saying is correct and I am not disputing that there is
sufficient cryptographic commitment in the signature message. As I tried to
explain, my proposal is about avoiding the need for the metadata protocol
you speak of. Avoiding such a protocol has been a design goal in both
BIP-143 [1, 2] and BIP-341 [3, 4], because having to acquire each of the
transactions being spent in their entirety places a significant burden on
offline signing devices.

Cheers,
Andrew

[1]
https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#motivation
[2] https://bitcointalk.org/index.php?topic=181734.0
[3]
https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#cite_note-16
[4]
https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#cite_note-17

On Fri, May 1, 2020 at 8:56 AM Jeremy <jlrubin@mit.edu> wrote:

> Hi Andrew,
>
> If you use SIGHASH_ALL it shall sign the COutPoints of all inputs which
> commit to the scriptPubKeys of the txn.
>
> Thus the 341 hash doesn't need to sign any additional data.
>
> As a metadata protocol you can provide all input transactions to check the
> scriptPubKeys.
>
> Best,
>
> Jeremy
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
>
>
> On Thu, Apr 30, 2020 at 1: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
>>
>

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

<div dir=3D"ltr">Hi Jeremy,<br><br>What you are saying is correct and I am =
not disputing that there is sufficient cryptographic commitment in the sign=
ature message. As I tried to explain, my proposal is about avoiding the nee=
d for the metadata protocol you speak of. Avoiding such a protocol has been=
 a design goal in both BIP-143 [1, 2] and BIP-341 [3, 4], because having to=
 acquire each of the transactions being spent in their entirety places a si=
gnificant burden on offline signing devices.<br><br>Cheers,<br>Andrew<br><b=
r>[1] <a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0143.media=
wiki#motivation" target=3D"_blank">https://github.com/bitcoin/bips/blob/mas=
ter/bip-0143.mediawiki#motivation</a><br>[2] <a href=3D"https://bitcointalk=
.org/index.php?topic=3D181734.0" target=3D"_blank">https://bitcointalk.org/=
index.php?topic=3D181734.0</a><br>[3] <a href=3D"https://github.com/bitcoin=
/bips/blob/master/bip-0341.mediawiki#cite_note-16" target=3D"_blank">https:=
//github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#cite_note-16</a><b=
r>[4] <a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0341.media=
wiki#cite_note-17" target=3D"_blank">https://github.com/bitcoin/bips/blob/m=
aster/bip-0341.mediawiki#cite_note-17</a></div><br><div class=3D"gmail_quot=
e"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, May 1, 2020 at 8:56 AM Jer=
emy &lt;<a href=3D"mailto:jlrubin@mit.edu" target=3D"_blank">jlrubin@mit.ed=
u</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"=
><div dir=3D"ltr"><div><div dir=3D"ltr"><div dir=3D"ltr"><div style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=
=3D"gmail_default">Hi Andrew,</div><div style=3D"font-family:arial,helvetic=
a,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><br>=
</div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;=
color:rgb(0,0,0)" class=3D"gmail_default">If you use SIGHASH_ALL it shall s=
ign the COutPoints of all inputs which commit to the scriptPubKeys of the t=
xn.</div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:sma=
ll;color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div style=3D"font-f=
amily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D=
"gmail_default">Thus the 341 hash doesn&#39;t need to sign any additional d=
ata.</div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:sm=
all;color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div style=3D"font-=
family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=
=3D"gmail_default">As a metadata protocol you can provide all input transac=
tions to check the scriptPubKeys.</div><div style=3D"font-family:arial,helv=
etica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">=
<br></div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:sm=
all;color:rgb(0,0,0)" class=3D"gmail_default">Best,</div><div style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=
=3D"gmail_default"><br></div><div style=3D"font-family:arial,helvetica,sans=
-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">Jeremy<br>=
</div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;=
color:rgb(0,0,0)" class=3D"gmail_default">--</div><a href=3D"https://twitte=
r.com/JeremyRubin" target=3D"_blank">@JeremyRubin</a></div></div></div><br>=
</div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">=
On Thu, Apr 30, 2020 at 1:22 AM Andrew Kozlik via bitcoin-dev &lt;<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin=
-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex"><div dir=3D"ltr">Hi everyone,<br><br>In the c=
urrent draft of BIP-0341 [1] the signature message commits to the scriptPub=
Key of the output being spent by the input. I propose that the signature me=
ssage should commit to the scriptPubKeys of *all* transaction inputs.<br><b=
r>In certain applications like CoinJoin, a wallet has to deal with transact=
ions containing external inputs. To calculate the actual amount that the us=
er is spending, the wallet needs to reliably determine for each input wheth=
er it belongs to the wallet or not. Without such a mechanism an adversary c=
an fool the wallet into displaying incorrect information about the amount b=
eing spent, which can result in theft of user funds [2].<br><br>In order to=
 ascertain non-ownership of an input which is claimed to be external, the w=
allet 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 implementat=
ion of lightweight air-gapped wallets and hardware wallets in general. If t=
he signature message would commit to the scriptPubKeys of all transaction i=
nputs, then the wallet would only need to acquire the scriptPubKey of the o=
utput being spent without having to acquire and verify the hash of the enti=
re previous transaction. If an attacker would provide an incorrect scriptPu=
bKey, then that would cause the wallet to generate an invalid signature mes=
sage.<br><div><br></div><div>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 inpu=
ts are precisely the ones that would not be included in any of the signatur=
e messages produced by the wallet.</div><div><br></div>The obvious way to i=
mplement this is to add another hash to the signature message:<br>sha_scrip=
tPubKeys (32): the SHA256 of the serialization of all scriptPubKeys of the =
previous 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://gith=
ub.com/bitcoin/bips/blob/master/bip-0341.mediawiki#common-signature-message=
" target=3D"_blank">https://github.com/bitcoin/bips/blob/master/bip-0341.me=
diawiki#common-signature-message</a><br>[2] <a href=3D"https://lists.linuxf=
oundation.org/pipermail/bitcoin-dev/2017-August/014843.html" target=3D"_bla=
nk">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-August/014=
843.html</a><br></div>
_______________________________________________<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>
</blockquote></div>

--00000000000032446b05a49240de--