Matias Alejo Garcia [ARCHIVE] on Nostr: 📅 Original date posted:2015-03-13 📝 Original message:Hello everyone, We are ...
📅 Original date posted:2015-03-13
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150313/af2f95d0/attachment.html>
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150313/af2f95d0/attachment.html>