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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <ematiu@gmail.com>) id 1YWGaO-0000zk-Ql
for bitcoin-development@lists.sourceforge.net;
Fri, 13 Mar 2015 03:48:32 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.223.177 as permitted sender)
client-ip=209.85.223.177; envelope-from=ematiu@gmail.com;
helo=mail-ie0-f177.google.com;
Received: from mail-ie0-f177.google.com ([209.85.223.177])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YWGaN-0007GA-HH
for bitcoin-development@lists.sourceforge.net;
Fri, 13 Mar 2015 03:48:32 +0000
Received: by iegc3 with SMTP id c3so81435811ieg.3
for <bitcoin-development@lists.sourceforge.net>;
Thu, 12 Mar 2015 20:48:26 -0700 (PDT)
X-Received: by 10.107.136.206 with SMTP id s75mr45283857ioi.8.1426218506050;
Thu, 12 Mar 2015 20:48:26 -0700 (PDT)
MIME-Version: 1.0
Sender: ematiu@gmail.com
Received: by 10.50.33.74 with HTTP; Thu, 12 Mar 2015 20:48:05 -0700 (PDT)
From: Matias Alejo Garcia <matias@bitpay.com>
Date: Fri, 13 Mar 2015 00:48:05 -0300
X-Google-Sender-Auth: 2AHdyRe-gknyZw2OLTGbzVfnu0U
Message-ID: <CA+vKqYfG=SoNAgTeD0C_Q7F2p6MWdWE90u7728g9s3=nkmNi4w@mail.gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a113eb1526ce6ab0511235fa5
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(ematiu[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1YWGaN-0007GA-HH
Subject: [Bitcoin-development] BIP32 Index Randomisation
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 13 Mar 2015 03:48:32 -0000
--001a113eb1526ce6ab0511235fa5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hello everyone,
We are working on bitcore-wallet-server (BWS), a HD multisig wallet
'facilitator'. We have a couple of questions regarding BIP32 path usage,
and we would love to have feedback from you before moving forward.
Currently the BWS instances hold the set of extended public keys of the
wallet's peers to be able to derive addresses.
Since this is a problem from the privacy point of view, we thought using
pseudo-random BIP32 paths, with a seed only known be the peers, so the
server will be able to verify that addresses submitted by peers belong to
the wallet, but will not be able to derive future wallet addresses.
The workflow would be something like:
```
Peer > getCurrentIndex
< Server [index]
Peer:
pathSeed =3D PRNG(seed, index);
Peer > createAddress(index, pathSeed);
Server:
derives the address and add it to the wallet.
< Server new address
Peer: Verifies the address and inform it the user.
```
This way, accessing server data won't reveal future wallet addresses. The
seed (only known by the peers) could
be derived from hashes of their xprivs, so wallet funds can still be
recover with:
1) The complete set of xprivs
2) The quorum of xprivs + the complete set of xpubs + the address seed.
Thanks a lot in advance for any comment on this schema.
mat=C3=ADas
--=20
BitPay.com
--001a113eb1526ce6ab0511235fa5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><br></div><div>Hello everyone,</div><div><br></div><d=
iv>We are working on bitcore-wallet-server (BWS), a HD multisig wallet '=
;facilitator'. We have a couple of questions regarding BIP32 path usage=
, and we would love to have feedback from you before moving forward.</div><=
div><br></div><div>Currently the BWS instances hold the set of extended pub=
lic keys of the wallet's peers to be able to derive =C2=A0addresses.</d=
iv><div><br></div><div>Since this is a problem from the privacy point of vi=
ew, we thought using pseudo-random =C2=A0BIP32 paths, with a seed only know=
n be the peers, so the server will be able to verify that addresses =C2=A0s=
ubmitted by peers belong to the wallet, but will not be able to derive futu=
re wallet addresses.</div><div><br></div><div>The workflow would be somethi=
ng like:</div><div><br></div><div>```</div><div>Peer > =C2=A0 getCurrent=
Index</div><div><br></div><div>< Server [index]</div><div><br></div><div=
>Peer:</div><div>=C2=A0 pathSeed =3D PRNG(seed, index);</div><div><br></div=
><div>Peer > createAddress(index, pathSeed);</div><div><br></div><div>Se=
rver:=C2=A0</div><div>=C2=A0 derives the address and add it to the wallet.<=
/div><div><br></div><div>< Server =C2=A0new address</div><div><br></div>=
<div>Peer: Verifies the address and inform it the user.</div><div>```</div>=
<div><br></div><div>This way, accessing server data won't reveal future=
wallet addresses. The seed (only known by the peers) could</div><div>be de=
rived from hashes of their xprivs, so wallet funds can still be recover wit=
h:</div><div>=C2=A0 1) The complete set of xprivs</div><div>=C2=A0 2) The q=
uorum of xprivs + the complete set of xpubs + the address seed.</div><div><=
br></div><div>Thanks a lot in advance for any comment on this schema.</div>=
<div><br></div><div>mat=C3=ADas</div><div><br></div>-- <br><div class=3D"gm=
ail_signature"><div dir=3D"ltr"><div>BitPay.com</div></div></div>
</div>
--001a113eb1526ce6ab0511235fa5--
|
