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
|
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 83FCD504
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 27 Jun 2019 02:11:37 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yb1-f180.google.com (mail-yb1-f180.google.com
[209.85.219.180])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4975D3D0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 27 Jun 2019 02:11:36 +0000 (UTC)
Received: by mail-yb1-f180.google.com with SMTP id j15so579192ybh.11
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 26 Jun 2019 19:11:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=bitcoinbank.co.jp; s=google;
h=mime-version:from:date:message-id:subject:to;
bh=OCnYZB2Zk15BbTUzNq8vhx6uxSZz52qTI7doUBolVqA=;
b=Mi3FQpbSE4z4fI5O4GI5hPU76Bm6MMyWHoycm3mmCBjjOPReOH+3l6vuOtRRVbqnbA
+TN/1IXbcsd2exDnIqbEuu9of9ade5IxBmwvOCWqMDmoCI9feEwPEWhwT8OCN0iS8r1c
J2Hr6vphAjd5hHBvorX8JLOQEj5F5+JKKRiDk1YrivZX7HY7bOzRpHbPp+SZgZS8pD1V
YbuFz0mzTVcbPqgf5iUnpx0KAWBYoH2VZVIKnwiWdryr0pEZRJoz17pPOd5TfgCRtzrc
/LiLylBQI8dGltGk7QOsMYtNkUkJgU1C2IdOLMz4Xg8XuZd+rgfTuZd4TA6LQt/Nx1yU
H4Vw==
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=OCnYZB2Zk15BbTUzNq8vhx6uxSZz52qTI7doUBolVqA=;
b=Bs5H6EImy7xbRfxwNm8VTp+zmt6NgOThfg7mswIxl36YfYaiuyNyEJOnoU6DVb7RhP
UFqehGVOHziYozE3rUOaFBX0rAHiMW0ec3Sm1xq6HPb/DH/OFygIy99nuCsgaljPBVgn
n7REP+kSpba1owQAxdF1JRJAHsu5gXbGoen10dlsxs8ln6G49WN1sa/Q8bpVkedYocxy
uPqXTDHhdSc3EBUtLv2TaC0+UZ00sdCyfyjU6HWSwRkzCA+tZSTE0rg8mX8yST5cFIdA
OnfrxG8YjJ0GkUAZPQ35i+wmHNfhBivXDSV681R6itR/QUijOnWgg/XJPR6khElWWsUc
GuZQ==
X-Gm-Message-State: APjAAAVTDQvt1nKrfhgXI+GM12l8RmlIkpiGZoGHk5PdhkuwFw1YjA/T
Pzk8w7W7wyMPtxLEkXm+K54eA/XAAqaQsD4UyP9+e5Vl5aZQ
X-Google-Smtp-Source: APXvYqyJVFt94hhRiHvXrdqCalbL3DgGBZ41YPKSicRsstVBa4IKr35GgLHd7NVrpAS3wh05d+ew7NyYNcORSgBFVpI=
X-Received: by 2002:a25:5557:: with SMTP id j84mr933026ybb.25.1561601495019;
Wed, 26 Jun 2019 19:11:35 -0700 (PDT)
MIME-Version: 1.0
From: Jonathan Underwood <junderwood@bitcoinbank.co.jp>
Date: Thu, 27 Jun 2019 11:11:23 +0900
Message-ID: <CAMpN3mLvY+kuUGqzMW6SAMZ=h46_g=XLhDPhSY=X6xhLxvi15Q@mail.gmail.com>
To: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000644589058c44ae2c"
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: Thu, 27 Jun 2019 03:17:17 +0000
Subject: [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: Thu, 27 Jun 2019 02:11:37 -0000
--000000000000644589058c44ae2c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Hello all,
Just wanted to pick your brains about an idea for PSBT extension.
One problem we try to solve with cold -> warm and warm -> hot sends for our
exchange wallet is "How do I know that the address I am sending to is not a
hacker's address that was swapped in between unsigned tx creation and first
signature?"
We have a proprietary JSON based encoding system which we are looking to
move towards PSBT, but PSBT is missing this key functionality.
BIP32_DERIVATION does allow us to verify the address is from a certain
XPUB, but, for example, it can not allow us to verify a signature of that
xpub.
I have made a rough draft of the proposed key value specification.
https://github.com/junderw/bips/blob/addXpubSig/bip-0174.mediawiki#specific=
ation
The signing key path used in the spec is just randomly chosen 31 x 4 bits
shown as numbers with hardened paths.
Since this issue seems similar to the change address issue, I started from
that as a base. With the HW wallet case, I can verify the xpub by just
deriving it locally and comparing equality, however, in our case, we need
to verify an xpub that we do not have access to via derivation from our
cold key(s) (since we don't want to import our warm private key into our
cold signer)
So the flow would be:
1. Securely verify the xpub of the warm / hot wallet.
2. Using the airgap signing tool, sign the xpub with all cold keys.
3. Upload the signature/xpub pairs to the online unsigned transaction
generator.
4. Include one keyval pair per coldkey/xpub pairing.
5. When offline signing, if the wallet detects there is a global keyval
XPUB_SIGNATURE with its pubkey in the key, it must verify that all outputs
have BIP32_DERIVATION and that it can verify the outputs through the
derivation, to the xpub, and to the signature.
In my attempt to fitting this into PSBT, I am slightly altering our current
system, so don't take this as an indication 100% of how we work in the
backend.
However, I would like to hear any feedback on this proposal.
Thanks,
Jonathan
--=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
--000000000000644589058c44ae2c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hello all,<div><br></div><div>Just wanted to pick your bra=
ins about an idea for PSBT extension.</div><div><br></div><div>One problem =
we try to solve with cold -> warm and warm -> hot sends for our excha=
nge wallet is "How do I know that the address I am sending to is not a=
hacker's address that was swapped in between unsigned tx creation and =
first signature?"</div><div><div><br></div><div>We have a proprietary =
JSON based encoding system which we are looking to move towards PSBT, but P=
SBT is missing this key functionality.<br><br>BIP32_DERIVATION does allow u=
s to verify the address is from a certain XPUB, but, for example, it can no=
t allow us to verify a signature of that xpub.<br><br>I have made a rough d=
raft of the proposed key value specification.<br><a href=3D"https://github.=
com/junderw/bips/blob/addXpubSig/bip-0174.mediawiki#specification">https://=
github.com/junderw/bips/blob/addXpubSig/bip-0174.mediawiki#specification</a=
><br></div><div><br></div><div>The signing key path used in the spec is jus=
t randomly chosen 31 x 4 bits shown as numbers with hardened paths.</div><d=
iv><br></div><div>Since this issue seems similar to the change address issu=
e, I started from that as a base. With the HW wallet case, I can verify the=
xpub by just deriving it locally and comparing equality, however, in our c=
ase, we need to verify an xpub that we do not have access to via derivation=
from our cold key(s) (since we don't want to import our warm private k=
ey into our cold signer)</div><div><br></div><div>So the flow would be:</di=
v><div>1. Securely verify the xpub of the warm / hot wallet.</div><div>2. U=
sing the airgap signing tool, sign the xpub with all cold keys.</div><div>3=
. Upload the signature/xpub pairs to the online unsigned transaction genera=
tor.<br>4. Include one keyval pair per coldkey/xpub pairing.<br>5. When off=
line signing, if the wallet detects there is a global keyval XPUB_SIGNATURE=
with its pubkey in the key, it must verify that all outputs have BIP32_DER=
IVATION and that it can verify the outputs through the derivation, to the x=
pub, and to the signature.</div><div><br></div><div>In my attempt to fittin=
g this into PSBT, I am slightly altering our current system, so don't t=
ake this as an indication 100% of how we work in the backend.</div><div><br=
></div><div>However, I would like to hear any feedback on this proposal.</d=
iv><div><br></div><div>Thanks,</div><div>Jonathan</div><div><br></div>-- <b=
r><div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_signat=
ure"><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: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3</=
div></div></div></div></div></div></div></div>
--000000000000644589058c44ae2c--
|
