[Bitcoin-development] BIP32 Index Randomisation
gmaxwell at gmail.com
Fri Mar 13 04:01:45 UTC 2015
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
iL = HMAC-SHA512(Key = cpar, Data = 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 at bitpay.com> wrote:
> 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]
> pathSeed = PRNG(seed, index);
> Peer > createAddress(index, pathSeed);
> 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
> 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.
> Dive into the World of Parallel Programming The Go Parallel Website,
> by Intel and developed in partnership with Slashdot Media, is your hub for
> things parallel software development, from weekly thought leadership blogs
> 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 at lists.sourceforge.net
More information about the bitcoin-dev