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
|
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 1Yft2J-0003v4-I3
for bitcoin-development@lists.sourceforge.net;
Wed, 08 Apr 2015 16:41:07 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.178 as permitted sender)
client-ip=209.85.216.178; envelope-from=swansontec@gmail.com;
helo=mail-qc0-f178.google.com;
Received: from mail-qc0-f178.google.com ([209.85.216.178])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Yft2I-0000nG-EQ
for bitcoin-development@lists.sourceforge.net;
Wed, 08 Apr 2015 16:41:07 +0000
Received: by qcrf4 with SMTP id f4so31872519qcr.0
for <bitcoin-development@lists.sourceforge.net>;
Wed, 08 Apr 2015 09:41:01 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.140.82.176 with SMTP id h45mr30197676qgd.75.1428511260972;
Wed, 08 Apr 2015 09:41:00 -0700 (PDT)
Received: by 10.140.149.23 with HTTP; Wed, 8 Apr 2015 09:41:00 -0700 (PDT)
In-Reply-To: <CACvEmnE6jgeRmTbyoOfW+jf=EB_EmPN4FdBXz-anm4tfKJscqw@mail.gmail.com>
References: <5524D347.4040507@maza.club>
<CABjHNoTbLz+dCPkctk95jPkdnagQQxOintYgswKCE6wB=TS9xg@mail.gmail.com>
<CACvEmnE6jgeRmTbyoOfW+jf=EB_EmPN4FdBXz-anm4tfKJscqw@mail.gmail.com>
Date: Wed, 8 Apr 2015 09:41:00 -0700
Message-ID: <CABjHNoR_Tg6bq3mJ8vkFAOPNHz8RS-FKAEx9APMZAVhct5H0SA@mail.gmail.com>
From: William Swanson <swansontec@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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
X-Headers-End: 1Yft2I-0000nG-EQ
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: Wed, 08 Apr 2015 16:41:07 -0000
Oops, sorry I missed that.
Since that's the reason this proposal exists, I would consider putting
it right up top where people can see it. Also, since this proposal is
specifically designed for multi-sig, I would look at what BIP45 is
doing and maybe incorporate a "cosigner_index" branch. Otherwise, this
idea seems like a reasonable way to organize a wallet.
-William
On Wed, Apr 8, 2015 at 9:28 AM, =E6=9C=A8=E3=83=8E=E4=B8=8B=E3=81=98=E3=82=
=87=E3=81=AA <kinoshitajona@gmail.com> wrote:
> William,
>
> I believe the reasoning for this is stated in the Coin Type section.
>
> "Public derivation is used so that cosigners need only know one of each
> other's public keys, rather than needing to distribute public keys for ea=
ch
> coin."
>
> BIP44 has a coin level, but it's a private derived level, so cosigners wo=
uld
> not be able to generate multiple crypto currencies of each others' withou=
t
> giving each other n xpubs where n is the number of currencies shared. Thi=
s
> new proposal basically sticks coin type on the public derivation side of
> things so that I could generate litecoin or darkcoin multisigs without yo=
ur
> permission...
>
> Kefkius,
>
> This BIP seems like a good fit for multi-currency wallets based on multis=
ig.
> So kudos for putting it in writing.
>
> However, I don't know if this is really a BIP thing. It's not improving
> Bitcoin (Bitcoin Improvement Proposal... remember?), in fact, by definiti=
on
> it is improving altcoin usability.
>
> For that reason alone I will say I disagree for a BIP for this.
> - Jona
>
>
> 2015-04-08 16:46 GMT+09:00 William Swanson <swansontec@gmail.com>:
>>
>> It's not really clear why this is better than BIP 44 as it already
>> stands. You have the same fields, but they are just in a different
>> order. Couldn't you just use the existing BIP 44 hierarchy, but add
>> the convention that "wallet/account N" is the same wallet in each
>> supported currency?
>>
>> For example, if I have a wallet called "business expenses", which
>> happens to be wallet m / 44' / 0' / 5', for Bitcoin, then the same
>> wallet would be m / 44' / 3' / 5' for Dogecoin, and m / 44' / 2' / 5'
>> for Litecoin.
>>
>> I am trying to think of examples where your proposal is better than
>> BIP 44, but I can't think of any. Even backup recovery works fine. I
>> assume that your idea is to continue iterating over the different
>> wallet indices as long as you are finding funds in *any* currency.
>> Well, you can still do that with BIP 44. The fields are in a different
>> order, but that doesn't affect the algorithm in any way.
>>
>> Maybe you have some deeper insight I'm not seeing, but if so, you need
>> to clearly explain that in your motivation section. The current
>> explanation, "This limits the possible implementations of
>> multi-currency, multisignature wallets," is pretty vauge. Also, there
>> is nothing in this spec that addresses the multisignature use-case.
>> The BIP 45 spec does a lot of extra work to make multisignature work
>> smoothly.
>>
>> I'm not trying to criticize your proposal. I'm just trying to
>> understand what it's trying to accomplish.
>>
>> -William Swanson
>>
>>
>> On Wed, Apr 8, 2015 at 12:05 AM, Kefkius <kefkius@maza.club> wrote:
>> > I have a potential BIP, "Multi-Currency Hierarchy For Use In
>> > Multisignature Deterministic Wallets." I'm requesting discussion on it=
,
>> > and possibly assignment of a BIP number.
>> >
>> > It's located in this github gist:
>> > https://gist.github.com/Kefkius/1aa02945e532f8739023
|
