public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Jean-Pierre Rupp <root@haskoin.com>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] [Bitcoin-development] New BIP32 structure for P2SH multisig wallets [BIP-45]
Date: Sun, 4 Oct 2015 16:18:07 +0100	[thread overview]
Message-ID: <5611432F.5070209@haskoin.com> (raw)
In-Reply-To: <560FCD30.9020902@haskoin.com>

I have a possible solution:

Take all public keys encoded in the purpose-specific extended public
keys (m/45') of all cosigners and sort them lexicographically, according
to BIP-45.  Serialize this information and calculate its HASH160
(RIPEMD160 ∘ HASH256).  Split the output in five 32-bit chunks, setting
the MSB on all of them to 0. Use these 32-bit chunks to build a
derivation path from the purpose-specific extended public keys.  Treat
this derivation path as if it was the purpose-specific extended public
key in BIP-45.

This scheme will avoid public key sharing, and as long as you share your
purpose-specific extended public key only with your cosigners, it should
be relatively hard for a passive observer to link activity between
different cosigning accounts.

On 03/10/15 13:42, Jean-Pierre Rupp via bitcoin-dev wrote:
> Hello,
> 
> I have been reviewing BIP-45 today.  There is a privacy problem with it
> that should at least be mentioned in the document.
> 
> When using the same extended public key for all multisig activity, and
> dealing with different cosigners in separate multisig accounts, reuse of
> the same set of public keys means that all cosigners from all accounts
> will be able to monitor multisig activity from every other cosigner, in
> every other account.
> 
> Besides privacy considerations, HD wallet's non-reuse of public keys
> provide some defence against wallets that do not implement deterministic
> signing, and use poor entropy for signature nonces.
> 
> Unless users are expected to establish a single cosigning account, this
> scheme will result in reuse of public keys, and degradation of privacy.
> 
> I understand that for convenience it is useful to have a single extended
> public key that can be handed to every cosigner.  This makes setting up
> accounts or recovering from data loss a easier.
> 
> I suggest that privacy & potential security degradation due to increased
> public key reuse in the case of users with multiple multisig accounts
> should get a mention in the BIP-45 document.
> 
> Greetings


  reply	other threads:[~2015-10-04 15:18 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-25 22:27 [Bitcoin-development] New BIP32 structure for P2SH multisig wallets Manuel Araoz
2014-04-26  3:02 ` Alan Reiner
2014-04-26  9:43 ` Mike Hearn
2014-04-26 10:08   ` Thomas Voegtlin
2014-04-28  1:37     ` Jeff Garzik
2014-04-26 11:36   ` Manuel Araoz
2014-04-26 20:33     ` Mike Hearn
2014-04-26 21:01       ` Alan Reiner
2014-04-26 21:57         ` Mike Hearn
2015-10-03 12:42 ` [bitcoin-dev] [Bitcoin-development] New BIP32 structure for P2SH multisig wallets [BIP-45] Jean-Pierre Rupp
2015-10-04 15:18   ` Jean-Pierre Rupp [this message]
2015-10-04 17:24     ` Thomas Kerin
2015-10-05  6:57       ` Matias Alejo Garcia
2015-10-05 12:18         ` Jean-Pierre Rupp
2015-10-05 12:32           ` Jonas Schnelli
2015-10-05 19:36             ` Jean-Pierre Rupp
2015-10-05 18:04           ` Matias Alejo Garcia
2015-10-05 11:43       ` Jean-Pierre Rupp

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5611432F.5070209@haskoin.com \
    --to=root@haskoin.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox