{"type":"rich","version":"1.0","author_name":"npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet","author_url":"https://nostr.ae/npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-03-13\n📝 Original message:This seems overly complicated to me, unless I'm missing something.\n\nInstead, I think you should just give the server the master pubkey P\nonly without the chaincode.\n\n\nThen when you transact you generate the address in whatever manner you\nlike and tell the server the scalar value iL which the user computes\nas\n\niL = HMAC-SHA512(Key = cpar, Data = serP(Kpar) || ser32(i))[first 32\nbyes],  (per BIP 32).\n\nand the server computes P + iL*G  and checks agreement with the address.\n\nIt would be inaccurate to call this private, as the server still\nlearns this particular relation. (and really users should _not_ be\nusing the same chaincode with different parties... as it exacerbates\nthe private key leak risk), but its certainly more private than giving\npeople the chain code.\n\nThe approach I suggest is also not gratuitously incompatible with\nhardened derivation, which is what parties should be doing when they\ndon't actually need a third party to generate future addresses for\nthem without their cooperation (as appears to be the case here).\n\n\n\n\n\n\n\n\n\n\nOn Fri, Mar 13, 2015 at 3:48 AM, Matias Alejo Garcia \u003cmatias at bitpay.com\u003e wrote:\n\u003e\n\u003e Hello everyone,\n\u003e\n\u003e We are working on bitcore-wallet-server (BWS), a HD multisig wallet\n\u003e 'facilitator'. We have a couple of questions regarding BIP32 path usage, and\n\u003e we would love to have feedback from you before moving forward.\n\u003e\n\u003e Currently the BWS instances hold the set of extended public keys of the\n\u003e wallet's peers to be able to derive  addresses.\n\u003e\n\u003e Since this is a problem from the privacy point of view, we thought using\n\u003e pseudo-random  BIP32 paths, with a seed only known be the peers, so the\n\u003e server will be able to verify that addresses  submitted by peers belong to\n\u003e the wallet, but will not be able to derive future wallet addresses.\n\u003e\n\u003e The workflow would be something like:\n\u003e\n\u003e ```\n\u003e Peer \u003e   getCurrentIndex\n\u003e\n\u003e \u003c Server [index]\n\u003e\n\u003e Peer:\n\u003e   pathSeed = PRNG(seed, index);\n\u003e\n\u003e Peer \u003e createAddress(index, pathSeed);\n\u003e\n\u003e Server:\n\u003e   derives the address and add it to the wallet.\n\u003e\n\u003e \u003c Server  new address\n\u003e\n\u003e Peer: Verifies the address and inform it the user.\n\u003e ```\n\u003e\n\u003e This way, accessing server data won't reveal future wallet addresses. The\n\u003e seed (only known by the peers) could\n\u003e be derived from hashes of their xprivs, so wallet funds can still be recover\n\u003e with:\n\u003e   1) The complete set of xprivs\n\u003e   2) The quorum of xprivs + the complete set of xpubs + the address seed.\n\u003e\n\u003e Thanks a lot in advance for any comment on this schema.\n\u003e\n\u003e matías\n\u003e\n\u003e --\n\u003e BitPay.com\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e Dive into the World of Parallel Programming The Go Parallel Website,\n\u003e sponsored\n\u003e by Intel and developed in partnership with Slashdot Media, is your hub for\n\u003e all\n\u003e things parallel software development, from weekly thought leadership blogs\n\u003e to\n\u003e news, videos, case studies, tutorials and more. Take a look and join the\n\u003e conversation now. http://goparallel.sourceforge.net/\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e"}