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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1YWGnI-0005Hz-Ii
for bitcoin-development@lists.sourceforge.net;
Fri, 13 Mar 2015 04:01:52 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.223.173 as permitted sender)
client-ip=209.85.223.173; envelope-from=gmaxwell@gmail.com;
helo=mail-ie0-f173.google.com;
Received: from mail-ie0-f173.google.com ([209.85.223.173])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YWGnH-000508-1X
for bitcoin-development@lists.sourceforge.net;
Fri, 13 Mar 2015 04:01:52 +0000
Received: by iecsl2 with SMTP id sl2so79671668iec.1
for <bitcoin-development@lists.sourceforge.net>;
Thu, 12 Mar 2015 21:01:45 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.107.153.193 with SMTP id b184mr81393813ioe.85.1426219305750;
Thu, 12 Mar 2015 21:01:45 -0700 (PDT)
Received: by 10.107.6.133 with HTTP; Thu, 12 Mar 2015 21:01:45 -0700 (PDT)
In-Reply-To: <CA+vKqYfG=SoNAgTeD0C_Q7F2p6MWdWE90u7728g9s3=nkmNi4w@mail.gmail.com>
References: <CA+vKqYfG=SoNAgTeD0C_Q7F2p6MWdWE90u7728g9s3=nkmNi4w@mail.gmail.com>
Date: Fri, 13 Mar 2015 04:01:45 +0000
Message-ID: <CAAS2fgSXR-njGtJgnvFpC8aT2L8Ch8D=_B8Rk-p0LG4JF0-ZyA@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Matias Alejo Garcia <matias@bitpay.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.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
(gmaxwell[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-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: 1YWGnH-000508-1X
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [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 04:01:52 -0000
This seems overly complicated to me, unless I'm missing something.
Instead, I think you should just give the server the master pubkey P
only without the chaincode.
Then when you transact you generate the address in whatever manner you
like and tell the server the scalar value iL which the user computes
as
iL =3D HMAC-SHA512(Key =3D cpar, Data =3D serP(Kpar) || ser32(i))[first 32
byes], (per BIP 32).
and the server computes P + iL*G and checks agreement with the address.
It would be inaccurate to call this private, as the server still
learns this particular relation. (and really users should _not_ be
using the same chaincode with different parties... as it exacerbates
the private key leak risk), but its certainly more private than giving
people the chain code.
The approach I suggest is also not gratuitously incompatible with
hardened derivation, which is what parties should be doing when they
don't actually need a third party to generate future addresses for
them without their cooperation (as appears to be the case here).
On Fri, Mar 13, 2015 at 3:48 AM, Matias Alejo Garcia <matias@bitpay.com> wr=
ote:
>
> 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 t=
o
> 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 reco=
ver
> 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
>
> --
> BitPay.com
>
> -------------------------------------------------------------------------=
-----
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub fo=
r
> all
> things parallel software development, from weekly thought leadership blog=
s
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
|
