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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <swansontec@gmail.com>) id 1YgOHH-0000ut-0P
for bitcoin-development@lists.sourceforge.net;
Fri, 10 Apr 2015 02:02:39 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.220.175 as permitted sender)
client-ip=209.85.220.175; envelope-from=swansontec@gmail.com;
helo=mail-qk0-f175.google.com;
Received: from mail-qk0-f175.google.com ([209.85.220.175])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YgOHG-0006Y3-04
for bitcoin-development@lists.sourceforge.net;
Fri, 10 Apr 2015 02:02:38 +0000
Received: by qku63 with SMTP id 63so8926862qku.3
for <bitcoin-development@lists.sourceforge.net>;
Thu, 09 Apr 2015 19:02:32 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.140.42.105 with SMTP id b96mr7920152qga.105.1428631352634;
Thu, 09 Apr 2015 19:02:32 -0700 (PDT)
Received: by 10.140.149.23 with HTTP; Thu, 9 Apr 2015 19:02:32 -0700 (PDT)
In-Reply-To: <5526FF23.9040402@gmail.com>
References: <5524D347.4040507@maza.club>
<CABjHNoTbLz+dCPkctk95jPkdnagQQxOintYgswKCE6wB=TS9xg@mail.gmail.com>
<CACvEmnE6jgeRmTbyoOfW+jf=EB_EmPN4FdBXz-anm4tfKJscqw@mail.gmail.com>
<CABjHNoR_Tg6bq3mJ8vkFAOPNHz8RS-FKAEx9APMZAVhct5H0SA@mail.gmail.com>
<5526DE29.1060605@maza.club>
<CABjHNoQq7OmkmawA-Z-ugd37EFTefh5KqjUThF=fbg1k4u_ThQ@mail.gmail.com>
<5526FF23.9040402@gmail.com>
Date: Thu, 9 Apr 2015 19:02:32 -0700
Message-ID: <CABjHNoQUMzUB+Q-dk+C=AzwXkVUC1fJOtVAB4TpXWhg2ONJdBg@mail.gmail.com>
From: William Swanson <swansontec@gmail.com>
To: Alan Reiner <etotheipi@gmail.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.6 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(swansontec[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
0.0 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1YgOHG-0006Y3-04
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Request For Discussion / BIP number -
Multi-Currency Hierarchy For Use In Multisignature Deterministic Wallets
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 10 Apr 2015 02:02:39 -0000
Hello Alan,
Your scheme is basically the same as the BIP45 scheme, except that you
have collapsed the "cosigner_index" and "change" fields into a single
field with the formula:
combined = 2*cosigner_index + change
This removes one level from the hierarchy, but ultimately produces the
same number and type of chains as BIP45 (just addressed differently).
I kinda like the BIP45's approach of giving each field has its own
dedicated purpose. What is the motivation behind flattening the
hierarchy?
I ask because the wallet I work on, Airbitz, will be adding multi-sig
at some point in the future, and we need to figure out what kind of HD
tree structure we will be using. Our ideal structure would basically
be BIP 44 plus some "no-collision" logic:
m / purpose' / coin_type' / wallet' / cosigner_index / change /
address_index
I feel like interoperability with Copay would be worth the extra HD
branch. Assuming Kefkius adds similar no-collision logic, his proposal
is pretty close to our ideal:
m / purpose' / wallet' / coin_type / cosigner_index / change / address_index
Of course, I am open to hearing your thoughts on this as well.
-William
On Thu, Apr 9, 2015 at 3:37 PM, Alan Reiner <etotheipi@gmail.com> wrote:
> BTW, I had originally proposed a "no-collision" scheme for
> multi-signature wallets, which doesn't require modifying the key tree
> structure at all, except for adding new internal and external chains
> (2*N chains). All siblings watch all chains, but only generate
> receiving and change addresses on their two chains.
>
> The original document is here, which might be educational for the
> purposes of understand precisely the problem that needs a solution (and
> mine is a different solution than BIP45).
>
> https://www.dropbox.com/s/58poxi60d8nfj5w/MultisigWalletNoCollide.pdf
>
> I prefer not adding even more levels to the key tree, and (IMO) it makes
> more sense to add more chains to the wallet instead of adding a new tree
> level (as it allows for a simpler tree in the event that you don't need
> separate cosigners). But I suspect that there's a certain momentum
> behind the cosigner-index method already in BIP45? Just throwing it out
> there.
|
