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
150
151
152
153
154
155
156
157
158
159
160
161
162
163
|
Return-Path: <thomas.kerin@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id D59471D6A
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 4 Oct 2015 17:25:08 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com
[209.85.212.172])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7DD242D2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 4 Oct 2015 17:25:07 +0000 (UTC)
Received: by wiclk2 with SMTP id lk2so91142571wic.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 04 Oct 2015 10:25:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=message-id:date:from:user-agent:mime-version:to:subject:references
:in-reply-to:content-type:content-transfer-encoding;
bh=ZCT4yG6DlNVHspWLZ8Os9Trn2WWJSIxkS+rNhk81RBo=;
b=U1sm7HtaTvL4rGlrm1WLe0N+Ncu1Vyn+5MMQARPmMYTedUD483QDtS8yv9PTJqkH72
j7ZuQYC+oGjD6u8NcqClPxdIOGWYsg11ZHf/NgiOWpq8c4ipNsD9hQaLYXuxorptRH5r
V1gRlzQNWydtpUJBAbEhd6Co6CBqBY6cv1bYofvqLNSV/igWB8OYrzs92MuQ4cguq/Ju
LNn6Zm/AG3OiTQQx8DHaG/xYkOTUxoeWRoFm7ShMhGjbNVcYMW7i6mtpRiSCyfHhyNzC
6mIZOhcGsMpKv/V7y0PSfEG17SMl+NgqzmKZCyn4A3WpbWAaA5P1AotOZew4AmjXEGBg
5mSQ==
X-Received: by 10.194.171.3 with SMTP id aq3mr26055881wjc.54.1443979505890;
Sun, 04 Oct 2015 10:25:05 -0700 (PDT)
Received: from [192.168.2.12] ([82.223.16.128])
by smtp.gmail.com with ESMTPSA id
bf8sm22539695wjc.22.2015.10.04.10.25.02
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Sun, 04 Oct 2015 10:25:04 -0700 (PDT)
Message-ID: <561160EB.30505@gmail.com>
Date: Sun, 04 Oct 2015 18:24:59 +0100
From: Thomas Kerin <thomas.kerin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:31.0) Gecko/20100101 Thunderbird/31.8.0
MIME-Version: 1.0
To: bitcoin-dev@lists.linuxfoundation.org, root@haskoin.com
References: <CABQSq2Q98K5zbUbQAqSE4OYez2QuOaWTt+9n5iZmSR2boynf_Q@mail.gmail.com> <560FCD30.9020902@haskoin.com>
<5611432F.5070209@haskoin.com>
In-Reply-To: <5611432F.5070209@haskoin.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
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
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: Sun, 04 Oct 2015 17:25:08 -0000
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi Jean Pierre,
This is a problem I've considered before, though I have to say I prefer
your solution.
The problem is, how can a person who restores his wallet from just a
seed restore
all his multi-signature addresses with other parties?
Your proposal is nice because all participants are equal, and it
minimalizes the data
required for recovery because it's deterministic, and the (extended)
public key is the first
piece of metadata you'll ask for from others.. Let it be the only thing
we need!
Regards amending BIP45 - BIP's are not amended after the fact, however
bad it may be
in retrospect. It might be best to write a BIP specifying a
"pseudorandom & deterministic
path generation for HD/multi-signature accounts"
TK
On 04/10/15 16:18, Jean-Pierre Rupp via bitcoin-dev wrote:
> 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
- --
My PGP key can be found here: <https://thomaskerin.io/me.pub.asc>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCgAGBQJWEWDlAAoJEAiDZR291eTlFAkQALgiiKX+VzLOwLK13S0EcE0v
RZeC8hqS5AEi/wpOYC2H0TFaHhDqDgy7Pt7nTt/vfOr9QFbJm076I/iFIhLPPAWf
rRg5kzL6ebOyX1NLmALcNgE9L+Jwz09kdzLUj+xZesJfu1AiSMgND38vFq4CmRfg
YSnWI4iMSP3OoMO5Akjq7m9Ww/lENPDmxTrz2ET9KwKPEkjrdt3c0ipQcs+/vGuU
RfRCUwxcdu/0nl5JhltxMV6wUMjdJ3AGbamWZpL+vA+jT5paOd4ORjc64huQGtFQ
W7l8ynbbVqtXlYYs9mXCMm70316sdo5ZpOXzQmplwtuHWVYt9ssS1aLkBoLYCBtU
i95Ki79S2ooeIjDEqI6FKpgVnLTmUbhudg/vk7eA0+RoNh3SBEHV2HmZ5yTBNtjk
P2a2tRmrbe3CmrdogbJzaweZenzoR82PziF7DAb/2JqtccPSdTW/GrAGyCoe0O5B
PId/iELHKpQepvybp+5PI6q2Atgzut4ze+a2vBiXjbiU3j0sX0XWg5fu9R9Ea1Bw
5+BY71GSa20OTDYEsp5esrl5/AUFj4ivB2OWFok77nGi2rTK+rKL3qMvbmYjAKUV
rWN4m6r8pU2hdhBCEJkXjg57whiMYn5w7ILlrbK5lLEu5qo0txoRtBPaid+y4mkK
moZU0LtvSQSX6ZaojQ/v
=Vs6z
-----END PGP SIGNATURE-----
|
