summaryrefslogtreecommitdiff
path: root/bb/c1fa5f6eec5d1d28acf6360754919d4e8757d0
blob: 5ba94bf108a655ad7366e0f002c698ced0bd834c (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
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 1152AC0172
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 29 Apr 2020 16:00:14 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by hemlock.osuosl.org (Postfix) with ESMTP id F01DB88281
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 29 Apr 2020 16:00:13 +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 ukmPx7nlNcs6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 29 Apr 2020 16:00:13 +0000 (UTC)
X-Greylist: delayed 00:40:45 by SQLgrey-1.7.6
Received: from mail-lj1-f174.google.com (mail-lj1-f174.google.com
 [209.85.208.174])
 by hemlock.osuosl.org (Postfix) with ESMTPS id CE578881D0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 29 Apr 2020 16:00:12 +0000 (UTC)
Received: by mail-lj1-f174.google.com with SMTP id b2so3194469ljp.4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 29 Apr 2020 09:00:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=satoshilabs.com; s=google;
 h=mime-version:from:date:message-id:subject:to;
 bh=ZPC2GhVZiUbEzlxsjE78pXXIwEJtQk1MccFirvtrSFg=;
 b=LORDlkSoz1RNDgdehjGL0UZ4JCc3Xgec9Y7fA8Wrl8/7LVjAh6Bkwy0Oq7Q5O+1n5F
 U2eTNlqrad5TV91AkYYS9vyOqMpxOQ7WNt71hyRMN0HWjr0nWPBQseRYHUOTY4qV0gC+
 SyUoZ/bmglzbvqbmIL/hgpdazCxfjuMfS5zdO0Wt1hNiQvaAb3f5Oo7BUHouDtV581Qa
 XREknnDra3p9zsx4QnhHQeX+HIyN55O3o4KbM4mDg4CYQU8XsWmRGlyK/kdvpBcvjAvh
 sYGAlGrhmzrLMLab8OqejpwOqpEIdjOhagDm2XO5nqPze3nI2UZK6V9U4H5/kZjVgl3i
 RakQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
 bh=ZPC2GhVZiUbEzlxsjE78pXXIwEJtQk1MccFirvtrSFg=;
 b=td5TxaYg0SKrNAAwsg5xhft7hjcWPohMhT1bpHw3OdfSI4bK9hgAx57IMZh0U0Jmn2
 Bd2TJooeOX9Lu/l3TYlDfQZiO17sGL/qX5YCmaBg/tCzRPwcPzb3F2iATw6lbwTsNcc8
 6ye7f8fU0cg+6n/4v8BPm2rJ/3Vf6RB/kvQQXHjQK8NF8Y4D+npu1r54kUKIDEGurC2z
 WpR9SNnFPOf9rgKowGq46DoBPdw3eDkAgjVyIgPiNQ9ek41PwS/KAeFMpdHuTpaId2Il
 JnFVWIZHCbaugd9E6hben4+P3WSVaAC+6IVJKM3lQLgxGmJVFKpDaSd58dhsgQ3mRXz1
 fjHA==
X-Gm-Message-State: AGi0PubbYtAPm2Z6DH/AcdWMxXbaW0wnMRDDHYj9AJ3Qq/cOCoLLZ1Z3
 JXawXvgow3K/w9iPDQGokC8WgjRiMTrZGya02HWa69MS
X-Google-Smtp-Source: APiQypLD+JojXK9qGAU/Uwd4isSZWetMgvsbHibFl2vvwq2yvq6e59exlswVJiijptSxK5M9okzOliTfdkcL9tqNrIY=
X-Received: by 2002:a17:906:35d0:: with SMTP id
 p16mr2875367ejb.77.1588172277719; 
 Wed, 29 Apr 2020 07:57:57 -0700 (PDT)
MIME-Version: 1.0
From: Andrew Kozlik <andrew.kozlik@satoshilabs.com>
Date: Wed, 29 Apr 2020 16:57:46 +0200
Message-ID: <CACvH2e=3s2kZWnytMySTv8U4pny3i0rEWas7NxzLxf5J7BewTg@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000074d51a05a46f2c7e"
X-Mailman-Approved-At: Thu, 30 Apr 2020 08:21:50 +0000
Subject: [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: Wed, 29 Apr 2020 16:00:14 -0000

--00000000000074d51a05a46f2c7e
Content-Type: text/plain; charset="UTF-8"

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

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

<div dir=3D"ltr">Hi everyone,<br><br>In the current draft of BIP-0341 [1] t=
he signature message commits to the scriptPubKey of the output being spent =
by the input. I propose that the signature message should commit to the scr=
iptPubKeys of *all* transaction inputs.<br><br>In certain applications like=
 CoinJoin, a wallet has to deal with transactions containing external input=
s. To calculate the actual amount that the user is spending, the wallet nee=
ds 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 displa=
ying incorrect information about the amount being spent, which can result i=
n theft of user funds [2].<br><br>In order to ascertain non-ownership of an=
 input which is claimed to be external, the wallet needs the scriptPubKey o=
f the previous output spent by this input. It must acquire the full transac=
tion being spent and verify its hash against that which is given in the out=
point. This is an obstacle in the implementation of lightweight air-gapped =
wallets and hardware wallets in general. If the signature message would com=
mit to the scriptPubKeys of all transaction inputs, then the wallet would o=
nly need to acquire the scriptPubKey of the output being spent without havi=
ng to acquire and verify the hash of the entire previous transaction. If an=
 attacker would provide an incorrect scriptPubKey, then that would cause th=
e wallet to generate an invalid signature message.<br><div><br></div><div>N=
ote that committing only to the scriptPubKey of the output being spent is i=
nsufficient for this application, because the scriptPubKeys which are neede=
d 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 wal=
let.</div><div><br></div>The obvious way to implement this is to add anothe=
r hash to the signature message:<br>sha_scriptPubKeys (32): the SHA256 of t=
he serialization of all scriptPubKeys of the previous outputs spent by this=
 transaction.<br><div><br></div><div>Cheers,<br></div><div>Andrew Kozlik</d=
iv><div><br></div>[1] <a href=3D"https://github.com/bitcoin/bips/blob/maste=
r/bip-0341.mediawiki#common-signature-message" target=3D"_blank">https://gi=
thub.com/bitcoin/bips/blob/master/bip-0341.mediawiki#common-signature-messa=
ge</a><br>[2] <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoi=
n-dev/2017-August/014843.html" target=3D"_blank">https://lists.linuxfoundat=
ion.org/pipermail/bitcoin-dev/2017-August/014843.html</a><br></div>

--00000000000074d51a05a46f2c7e--