diff options
| author | Matias Alejo Garcia <matias@bitpay.com> | 2015-03-13 00:48:05 -0300 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-03-13 03:48:32 +0000 |
| commit | 7c0d16708421f0b6ed48fcec59ddd9a6fcd14e84 (patch) | |
| tree | c208c3b6c251fb2cfe740a27dda43aab3383f107 | |
| parent | 15b7f1451226dbb3398ef4f7e5407a166a5f9014 (diff) | |
| download | pi-bitcoindev-7c0d16708421f0b6ed48fcec59ddd9a6fcd14e84.tar.gz pi-bitcoindev-7c0d16708421f0b6ed48fcec59ddd9a6fcd14e84.zip | |
[Bitcoin-development] BIP32 Index Randomisation
| -rw-r--r-- | 6f/0a92e9a78f8e6b3eb429d01d6da3d675a89a97 | 145 |
1 files changed, 145 insertions, 0 deletions
diff --git a/6f/0a92e9a78f8e6b3eb429d01d6da3d675a89a97 b/6f/0a92e9a78f8e6b3eb429d01d6da3d675a89a97 new file mode 100644 index 000000000..0f9ea85e1 --- /dev/null +++ b/6f/0a92e9a78f8e6b3eb429d01d6da3d675a89a97 @@ -0,0 +1,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-- + + |