1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
|
Return-Path: <root@haskoin.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 491AC1C43
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <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>
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: <CA+vKqYeBDHEGRgCsuAp3wQKb9idH085e5K3uNdeRLFvc9MTpdQ@mail.gmail.com>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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
|
