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
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
|
Return-Path: <junderwood@bitcoinbank.co.jp>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id C113D504
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 28 Jun 2019 02:44:28 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yw1-f44.google.com (mail-yw1-f44.google.com
[209.85.161.44])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0933B13A
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 28 Jun 2019 02:44:27 +0000 (UTC)
Received: by mail-yw1-f44.google.com with SMTP id s5so2633013ywd.9
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 27 Jun 2019 19:44:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=bitcoinbank.co.jp; s=google;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=UikQbEXlERtp8i+0KU6alV8FHf21Np+/0AyU0tkJ1Zw=;
b=kVvP38GAkjKVR3hLboku2jBJznbHzqBYhnSc1ZmSQA2YMBx0weXZ7H9fYD5NZqagog
C80SO1sP/dLL/STgSMNzWWqjNgG7tc11xGIptFSdel5WdrQBsFh84q4QTaW5J51P1Z5S
ImWclQVpfys4yh03j0tX+baoSCodncXW0p+a/jEE139bM+WM8bbkXu414W2dKRDjYMts
DS9xA8NvZghhinpL4MqDj2ZBlFn3mQJfjbkshInVqWNZQ4zw3jytaC0sCQ6Geo77+Y9O
6/5ZPTcH7j5Gea8F1/m8wOuIa9FUjF8t8UZIjhdlTQJzH8WgLrpR6y6nU1lzLGHE7u56
L4jw==
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=UikQbEXlERtp8i+0KU6alV8FHf21Np+/0AyU0tkJ1Zw=;
b=ZGj3Pv2yFp6QaRdzpvSTOiQ44cFC5IPia+mnHPXFFY4KuGbpDNs9/lgb/DVHORPUkZ
5BR8gL7P1yqK/+NQQGf7fSryE6Km5LniHacqOefH4AJgrtjaZMjaQGMqC1aw99ZAq2Af
yoWJ7und8Q2kytWaTvPygrQYPLkxE1POSwAh4qEU6nNIbqjx/T3UT71EfXBeJF86gibS
lfeVg6T+o3ixfCK4wyCcHEKozSvoYC4ir9v1OXR55+GNR3FA1i7N5qAxSjyQR+Z36tmh
epEccL1Ofm5iQdcFdbdgsXDwJB6r18Q/VxVo1Ev01a/2kMyZ43EF8lTj8FsP+mtYcc0Q
jj+w==
X-Gm-Message-State: APjAAAW3d/3ayxAU/H4xML3KaYx9bVNb0/eK92amON+Wq39wfBGEB7T/
ATg4ireUVPrAmLe5DnfM82tbfi8Dqb1g7+1dLEL3
X-Google-Smtp-Source: APXvYqyWARvE9w9WnK41jQA8ks3KZ8flH2Un6A+YuOiUyaU9ckjCHyDC2hHbKmVmlbYg+j0pON8F94BlNzCO3qgD5f0=
X-Received: by 2002:a0d:d656:: with SMTP id y83mr4362486ywd.79.1561689866985;
Thu, 27 Jun 2019 19:44:26 -0700 (PDT)
MIME-Version: 1.0
References: <CAMpN3mLvY+kuUGqzMW6SAMZ=h46_g=XLhDPhSY=X6xhLxvi15Q@mail.gmail.com>
<20190627095031.4d5817b8@simplexum.com>
<CAMpN3mKPkCPtYkN-JVku1r217-aBK=Rh3UEhvRPS_Y6DixJ9Dw@mail.gmail.com>
<20190627122916.3b6c2c32@simplexum.com>
<CAMpN3mL8tyP-6-nwn6dorcq7-dad6wYz8_pXinqHhgzUnrr_tg@mail.gmail.com>
<20190627134628.4d131264@simplexum.com>
<CAMpN3m+LiSW=kRCQio+C_2To66o_SEq-d_0Z122j+BUxvh=LDQ@mail.gmail.com>
<20190627142120.2c24fddb@simplexum.com>
<CAMpN3m+0HJm+zZ81ZNP-BXpX_39BvHzwKRAPwpdHinJ13gdNeA@mail.gmail.com>
<20190627150745.GA1897@coinkite.com>
In-Reply-To: <20190627150745.GA1897@coinkite.com>
From: Jonathan Underwood <junderwood@bitcoinbank.co.jp>
Date: Fri, 28 Jun 2019 11:44:15 +0900
Message-ID: <CAMpN3mKyKjSPs2SgC0pUbFMNXFZt7UOu4ktnbfBSDmLrDbafFA@mail.gmail.com>
To: Peter Gray <peter@coinkite.com>
Content-Type: multipart/alternative; boundary="000000000000c57b29058c594174"
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: Fri, 28 Jun 2019 03:20:46 +0000
Cc: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP174 extension proposal (Global Type:
PSBT_GLOBAL_XPUB_SIGNATURE)
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: Fri, 28 Jun 2019 02:44:28 -0000
--000000000000c57b29058c594174
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hi Peter,
tl;dr The problem this solves is "How can a signer verify an address with
HD changing the address every time?"
As an aside: (This is sort of explaining the current PR for the 0x01 global
field (separate from mine))
The problem is more easily understood with change addresses: If someone can
alter my PSBT before signing, they could replace my change address with
their address, and my signer would not know unless the signer just guesses
all the path sets it knows, then derives thousands of change addresses and
searches (most likely a signer is offline, so gap limit doesn't work since
we can't tell which change addresses have tx history. So the 0x01 global
tag will tell the signer "here's how you get from your master private key
to the xpub used in the change output's output BIP32_DERIVATION tag... you
can then derive the same key and check it is yours before signing."
Back to my proposal, this problem extends across wallets, since,
for example, if I want to send from my cold wallet to my warm wallet, I
don't want to give my cold signer my warm master key just so it can derive
and check the key. That's what signatures are for. So this proposal says "A
signer can be built to only sign if it sees a signature that itself has
signed, then from that signed xpub(s) derives the BIP32_DERIVATION in the
outputs, and if the output doesn't match it will reject and not sign"
This creates a sort of "chain of trust" for the wallet.
Currently the best way to prevent this (hacker swapping the send to
address) without using signatures is to reuse the same address every time
you want to send to the warm wallet, since after a few times, the signers
(people) will be able to remember the address.
This is a huge HD drawback for high security requirement environments.
Having this data in the PSBT standard will allow Trezor etc. to create an
enforceable whitelist feature.
Let me know if you have feedback on the details.
Thanks,
Jon
2019=E5=B9=B46=E6=9C=8828=E6=97=A5(=E9=87=91) 0:07 Peter D. Gray <peter@coi=
nkite.com>:
> I haven't studied the new proposal in depth, but my first impression is:
>
> Wouldn't it just be easier and better to just sign the entire "outputs"
> section of the PSBT?
>
> The signature would cover every byte, and therefore would cover any
> future BIP additions to the outputs area, and also help non-multisig
> cases today.
>
> ---
> Peter D. Gray || Founder, Coinkite || Twitter: @dochex || GPG:
> A3A31BAD 5A2A5B10
>
>
--=20
-----------------
Jonathan Underwood
=E3=83=93=E3=83=83=E3=83=88=E3=83=90=E3=83=B3=E3=82=AF=E7=A4=BE =E3=83=81=
=E3=83=BC=E3=83=95=E3=83=93=E3=83=83=E3=83=88=E3=82=B3=E3=82=A4=E3=83=B3=E3=
=82=AA=E3=83=95=E3=82=A3=E3=82=B5=E3=83=BC
-----------------
=E6=9A=97=E5=8F=B7=E5=8C=96=E3=81=97=E3=81=9F=E3=83=A1=E3=83=83=E3=82=BB=E3=
=83=BC=E3=82=B8=E3=82=92=E3=81=8A=E9=80=81=E3=82=8A=E3=81=AE=E6=96=B9=E3=81=
=AF=E4=B8=8B=E8=A8=98=E3=81=AE=E5=85=AC=E9=96=8B=E9=8D=B5=E3=82=92=E3=81=94=
=E5=88=A9=E7=94=A8=E4=B8=8B=E3=81=95=E3=81=84=E3=80=82
=E6=8C=87=E7=B4=8B: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
--000000000000c57b29058c594174
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Peter,<div><br></div><div>tl;dr The problem this solves=
is "How can a signer verify an address with HD changing the address e=
very time?"</div><div><br></div><div>As an aside: (This is sort of exp=
laining the current PR for the 0x01 global field (separate from mine))</div=
><div>The problem is more easily understood with change addresses: If someo=
ne can alter my PSBT before signing, they could replace my change address w=
ith their address, and my signer would not know unless the signer just gues=
ses all the path sets it knows, then derives thousands of change addresses =
and searches (most likely a signer is offline, so gap limit doesn't wor=
k since we can't tell which change addresses have tx history. So the 0x=
01 global tag will tell the signer "here's how you get from your m=
aster private key to the xpub used in the change output's output BIP32_=
DERIVATION tag... you can then derive the same key and check it is yours be=
fore signing."<br><br>Back to my proposal, this problem extends across=
wallets, since, for=C2=A0example, if I want to send from my cold wallet to=
my warm wallet, I don't want to give my cold signer my warm master key=
just so it can derive and check the key. That's what signatures are fo=
r. So this proposal says "A signer can be built to only sign if it see=
s a signature that itself has signed, then from that signed xpub(s) derives=
the BIP32_DERIVATION in the outputs, and if the output doesn't match i=
t will reject and not sign"</div><div><br></div><div>This creates a so=
rt of "chain of trust" for the wallet.</div><div><br></div><div>C=
urrently the best way to prevent this (hacker swapping the send to address)=
without using signatures is to reuse the same address every time you want =
to send to the warm wallet, since after a few times, the signers (people) w=
ill be able to remember the address.</div><div><br></div><div>This is a hug=
e HD drawback for high security requirement environments. Having this data =
in the PSBT standard will allow Trezor etc. to create an enforceable whitel=
ist feature.</div><div><br></div><div>Let me know if you have feedback on t=
he details.</div><div><br></div><div>Thanks,</div><div>Jon</div></div><br><=
div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">2019=E5=B9=
=B46=E6=9C=8828=E6=97=A5(=E9=87=91) 0:07 Peter D. Gray <<a href=3D"mailt=
o:peter@coinkite.com">peter@coinkite.com</a>>:<br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex">I haven't studied the new proposal in=
depth, but my first impression is:<br>
<br>
Wouldn't it just be easier and better to just sign the entire "out=
puts" section of the PSBT?<br>
<br>
The signature would cover every byte, and therefore would cover any<br>
future BIP additions to the outputs area, and also help non-multisig<br>
cases today.<br>
<br>
---<br>
Peter D. Gray=C2=A0 ||=C2=A0 Founder, Coinkite=C2=A0 ||=C2=A0 Twitter: @doc=
hex=C2=A0 ||=C2=A0 GPG: A3A31BAD 5A2A5B10<br>
<br>
</blockquote></div><br clear=3D"all"><div><br></div>-- <br><div dir=3D"ltr"=
class=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div dir=
=3D"ltr"><div>-----------------<br></div><div>Jonathan Underwood</div><div>=
=E3=83=93=E3=83=83=E3=83=88=E3=83=90=E3=83=B3=E3=82=AF=E7=A4=BE=E3=80=80=E3=
=83=81=E3=83=BC=E3=83=95=E3=83=93=E3=83=83=E3=83=88=E3=82=B3=E3=82=A4=E3=83=
=B3=E3=82=AA=E3=83=95=E3=82=A3=E3=82=B5=E3=83=BC</div><div>----------------=
-</div><div><br></div><div>=E6=9A=97=E5=8F=B7=E5=8C=96=E3=81=97=E3=81=9F=E3=
=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8=E3=82=92=E3=81=8A=E9=80=81=E3=82=
=8A=E3=81=AE=E6=96=B9=E3=81=AF=E4=B8=8B=E8=A8=98=E3=81=AE=E5=85=AC=E9=96=8B=
=E9=8D=B5=E3=82=92=E3=81=94=E5=88=A9=E7=94=A8=E4=B8=8B=E3=81=95=E3=81=84=E3=
=80=82</div><div><br></div><div>=E6=8C=87=E7=B4=8B: 0xCE5EA9476DE7D3E45EBC3=
FDAD998682F3590FEA3</div></div></div></div></div></div>
--000000000000c57b29058c594174--
|