rich1.0npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwethttps://nostr.ae/npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetnjumphttps://nostr.ae📅 Original date posted:2015-03-13 📝 Original message: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 = 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 >