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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jgarzik@bitpay.com>) id 1We554-0006so-TE
for bitcoin-development@lists.sourceforge.net;
Sat, 26 Apr 2014 16:03:58 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of bitpay.com
designates 74.125.82.41 as permitted sender)
client-ip=74.125.82.41; envelope-from=jgarzik@bitpay.com;
helo=mail-wg0-f41.google.com;
Received: from mail-wg0-f41.google.com ([74.125.82.41])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1We553-0006LR-Rp
for bitcoin-development@lists.sourceforge.net;
Sat, 26 Apr 2014 16:03:58 +0000
Received: by mail-wg0-f41.google.com with SMTP id y10so2083103wgg.12
for <bitcoin-development@lists.sourceforge.net>;
Sat, 26 Apr 2014 09:03:51 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc:content-type;
bh=hB9BbmjEdCJhlVRzcEyORaEEhdlVnoBjMyghjWnTtik=;
b=Ul3KGHMEd+gfM3R4CSrYwg7FV+d6EJDQZ4SJwrJWhc7B1XkRvEUTIhmQV32Fh3g1HI
n8yzDYW6oRHgdoMCl3yZ2qrJpU3cj6W8rqklVB05wlTlIOZd0oO4p65BMPDoBZLp6M1h
qhlOQZPPktyuGOCRavT354WDWqxpEwylC2kzz/DRAmA6LoKsNZfA2zsZZiIecSREkvk3
Or03AbUs4BW7cAASGlTwRUoptPDXpq2FM56hpGZtaYJuW5cBOVwBGWs3tbEslr8wEcHT
E0TIrFqOPUy72BQG5xeRRsPdp6SdwuyHfBYCaBMuBhkS6SIFPPaI2ypXd89lZn+OGUmt
hz7A==
X-Gm-Message-State: ALoCoQlz8X8hgziCi1p2CJmCGfZGqgbW5uewSqxmhfvwcXAV88KTmWjezm5bLZiV9o4BCx85XOVL
X-Received: by 10.194.205.161 with SMTP id lh1mr11464076wjc.40.1398528231477;
Sat, 26 Apr 2014 09:03:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.243.138 with HTTP; Sat, 26 Apr 2014 09:03:31 -0700 (PDT)
In-Reply-To: <CAAS2fgRiXdOBN2gVZ0Xh4kBeOKiS80AjD5+VxJEut9nWt-0WUg@mail.gmail.com>
References: <ljdd29$522$1@ger.gmane.org>
<1398437607.23028.110362141.03111A2A@webmail.messagingengine.com>
<CAAS2fgRiXdOBN2gVZ0Xh4kBeOKiS80AjD5+VxJEut9nWt-0WUg@mail.gmail.com>
From: Jeff Garzik <jgarzik@bitpay.com>
Date: Sat, 26 Apr 2014 12:03:31 -0400
Message-ID: <CAJHLa0MN=guCAzzJR7ex5dVjUQLJynaYBR3M4De5S0Ug5KBHhw@mail.gmail.com>
To: Gregory Maxwell <gmaxwell@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
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 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: 1We553-0006LR-Rp
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP32 "wallet structure" in use? Remove
it?
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: Sat, 26 Apr 2014 16:03:59 -0000
It is very young in bitcoin's life. We don't know what features will
work out best, or need to be radically changed after initial
deployment in the field.
Loose coordination is good. Good ideas will spread on their own.
Users will demand compatibility with certain features, and fail to
care incompatibilities in other features.
Tight interoperability at this stage is too confining.
On Fri, Apr 25, 2014 at 11:46 AM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
> On Fri, Apr 25, 2014 at 7:53 AM, Jim <jim618@fastmail.co.uk> wrote:
>> Oh dear.
>>
>> For reasons that are perfectly reasonable we are close to losing any chance of intra-client HD compatibility for BIP32 wallets.
>>
>> In the next 12 months there will probably be collectively millions of users of our new wallets. I don't want them to suffer from vendor lockin.
>>
>> Can we not agree on a lowest common denominator that we agree to support ?
>> An "HD Basic" if you like.
>> For entry level users we can keep things simple and any "HD Basic" bitcoin will be fully interoperable.
>>
>> Sure, if you use anything fancy you'll be locked in to a particular wallet but a lot of users just want somewhere safe to put their bitcoin, spend it and receive it.
>>
>> I appreciate standising everything is very difficult (if not impossible) but if we don't have a minimum of interoperability I think we'll do our users a disservice.
>
> I don't believe that wallet interoperability at this level is possible
> in general except as an explicit compatibility feature. I also don't
> believe that it is a huge loss that it is so.
>
> The structure of the derivation defines and constrains functionality.
> You cannot be structure compatible unless you have the same features
> and behavior with respect to key management. To that extent that
> wallets have the same features, I agree its better if they are
> compatible-- but unless they are dead software they likely won't keep
> the same features for long.
>
> Even if their key management were compatible there are many other
> things that go into making a wallet portable between systems; the
> handling of private keys is just one part: a complete wallet will
> have other (again, functionality specific) metadata.
>
> I agree that it would be it would be possible to support a
> compatibility mode where a wallet has just a subset of features which
> works when loaded into different systems, but I'm somewhat doubtful
> that it would be widely used. The decision to use that mode comes at
> the wrong time-- when you start, not when you need the features you
> chose to disable or when you want to switch programs. But the obvious
> thing to do there is to just specify that a linear chain with no
> further branching is that mode: then that will be the same mode you
> use when someone gives you a master public key and asks you to use it
> for reoccurring changes-- so at least the software will get used.
>
> Compatibility for something like a recovery tool is another matter,
> and BIP32 probably defines enough there that with a bit of extra data
> about how the real wallet worked that recovery can be successful.
>
> Calling it "vendor lock in" sounds overblown to me. If someone wants
> to change wallets they can transfer the funds-- manual handling of
> private keys is seldom advisable, and as is they're going to lose
> their metadata in any case. No one expects to switch banks and to
> keep their account records at the new bank. And while less than
> perfect, the price of heavily constraining functionality in order to
> get another result is just too high.
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc. https://bitpay.com/
|
