{"type":"rich","version":"1.0","author_name":"npub1p6uknnmm7wknvg9cq5wqsf7ulpsrdzd6zt6qw707y5t05fuzvfdsx8etde","author_url":"https://nostr.ae/npub1p6uknnmm7wknvg9cq5wqsf7ulpsrdzd6zt6qw707y5t05fuzvfdsx8etde","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-03-13\n📝 Original message:Hello everyone,\n\nWe are working on bitcore-wallet-server (BWS), a HD multisig wallet\n'facilitator'. We have a couple of questions regarding BIP32 path usage,\nand we would love to have feedback from you before moving forward.\n\nCurrently the BWS instances hold the set of extended public keys of the\nwallet's peers to be able to derive  addresses.\n\nSince this is a problem from the privacy point of view, we thought using\npseudo-random  BIP32 paths, with a seed only known be the peers, so the\nserver will be able to verify that addresses  submitted by peers belong to\nthe wallet, but will not be able to derive future wallet addresses.\n\nThe workflow would be something like:\n\n```\nPeer \u003e   getCurrentIndex\n\n\u003c Server [index]\n\nPeer:\n  pathSeed = PRNG(seed, index);\n\nPeer \u003e createAddress(index, pathSeed);\n\nServer:\n  derives the address and add it to the wallet.\n\n\u003c Server  new address\n\nPeer: Verifies the address and inform it the user.\n```\n\nThis way, accessing server data won't reveal future wallet addresses. The\nseed (only known by the peers) could\nbe derived from hashes of their xprivs, so wallet funds can still be\nrecover with:\n  1) The complete set of xprivs\n  2) The quorum of xprivs + the complete set of xpubs + the address seed.\n\nThanks a lot in advance for any comment on this schema.\n\nmatías\n\n-- \nBitPay.com\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150313/af2f95d0/attachment.html\u003e"}