To: Matias Alejo Garcia <matias@bitpay.com>,
	Thomas Kerin <thomas.kerin@gmail.com>
References: <CABQSq2Q98K5zbUbQAqSE4OYez2QuOaWTt+9n5iZmSR2boynf_Q@mail.gmail.com>
	<560FCD30.9020902@haskoin.com> <5611432F.5070209@haskoin.com>
	<561160EB.30505@gmail.com>
	<CA+vKqYeBDHEGRgCsuAp3wQKb9idH085e5K3uNdeRLFvc9MTpdQ@mail.gmail.com>
From: Jean-Pierre Rupp <root@haskoin.com>
Message-ID: <56126AB0.3030107@haskoin.com>
Date: Mon, 5 Oct 2015 13:18:56 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
	Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <CA+vKqYeBDHEGRgCsuAp3wQKb9idH085e5K3uNdeRLFvc9MTpdQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] [Bitcoin-development] New BIP32 structure for
 P2SH multisig wallets [BIP-45]
Precedence: list

When I talk about multisig account I mean an arrangement among a set of
cosigners to be signatories of multi-signature transactions requiring a
set number of signatures, as specified in BIP-45.

Example:

Juan: xpub123...
Pedro: xpub456...
José: xpub789...

They all agree to create a 2-of-3 multisig “account” following BIP-45.
Their extended public keys are all path m/45' from their wallet’s master
private key, as per the standard.

Perhaps Pedro wants to also participate in a 2-of-2 cosigning
arrangement with a merchant that will deliver a laptop to him, so Pedro
provides this merchant with the same extended public key derived from
path m/45', and the merchant provides Pedro with his own:

Pedro: xpub456...
ElCheapoPC: xpub987...

Now, suppose that the first cosigner[1] in each of the accounts
generates a set of public keys for a multisig redeem script to obtain a
P2SH address from. The derivation path m/45'/0/0/1 is used as per
BIP-45.  Pedro’s public key for that address in each account will be the
same.

Every cosigner’s address public key is obtained following the same
derivation path from the cosigner’s master key, therefore, it is easy to
know what public keys Pedro is likely to use in both 2-of-3 account
{Juan, Pedro, José} and 2-of-2 account {Pedro, ElCheapoPC}, by only
knowing Pedro’s m/45' purpose-specific extended public key.  By scanning
the blockchain for Pedro’s public keys, José can see that Pedro had a
2-of-2 multi-signature arrangement with somebody else (ElCheapoPC),
although he does not necessarily know its identity, and how much money
was transacted in that arrangement, without having to know the extended
public key from ElCheapoPC.

By adopting the scheme I proposed earlier as an improvement, cosigners
with Pedro would have to know ElCheapoPC’s extended public key in order
to eavesdrop on any transaction between Pedro and ElCheapoPC.

[1] According to lexicographic order of serialized public keys contained
in each of the xpubs, as per BIP-45 specification.

On 05/10/15 07:57, Matias Alejo Garcia wrote:
> 
> Hi,
> 
> Sorry the late response. Going back to the original message:
>  
> 
>     > On 03/10/15 13:42, Jean-Pierre Rupp via bitcoin-dev wrote:
>     >> 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.
> 
> 
> I am not completely sure what you mean by 'account' and 'mutisig
> activity'. You seem to imply
> that the same set of extended public keys will be used in more that one
> wallet, which it is 
> not required (and certainly not recommended) by BIP45.
> 
> According to BIP45, a singing party, in order to generate a wallet
> address, needs the extended public keys of all the other parties, so
> each party will be able to see the transaction history of the wallet
> they are sharing, but if the party has other wallets with other copayers
> the xpub should be completely different.
> 
> matías
> 
> 
> 
> -- 
> BitPay.com