[Bitcoin-development] BIP32 Index Randomisation

Gregory Maxwell 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]
> Peer:
>   pathSeed = 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ías
> --
> 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 for
> all
> things parallel software development, from weekly thought leadership blogs
> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

More information about the bitcoin-dev mailing list