From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 491AC1C43 for ; Mon, 5 Oct 2015 12:19:02 +0000 (UTC) X-Greylist: delayed 21:00:40 by SQLgrey-1.7.6 Received: from imap1-1.ox.privateemail.com (imap1-1.ox.privateemail.com [198.187.29.239]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9677E1B4 for ; Mon, 5 Oct 2015 12:19:01 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by imap1.ox.privateemail.com (Postfix) with ESMTP id 216A6B000CC; Mon, 5 Oct 2015 08:19:00 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at imap1.ox.privateemail.com Received: from imap1.ox.privateemail.com ([127.0.0.1]) by localhost (imap1.ox.privateemail.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id UPcvPkHlnGYC; Mon, 5 Oct 2015 08:18:59 -0400 (EDT) Received: from [192.168.44.30] (unknown [95.83.250.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by imap1.ox.privateemail.com (Postfix) with ESMTPSA id 600FAB00068; Mon, 5 Oct 2015 08:18:57 -0400 (EDT) To: Matias Alejo Garcia , Thomas Kerin References: <560FCD30.9020902@haskoin.com> <5611432F.5070209@haskoin.com> <561160EB.30505@gmail.com> From: Jean-Pierre Rupp X-Enigmail-Draft-Status: N1110 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: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] [Bitcoin-development] New BIP32 structure for P2SH multisig wallets [BIP-45] X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 12:19:02 -0000 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