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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <thomasv1@gmx.de>) id 1WdEoZ-0003zn-3f
for bitcoin-development@lists.sourceforge.net;
Thu, 24 Apr 2014 08:15:27 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmx.de
designates 212.227.17.21 as permitted sender)
client-ip=212.227.17.21; envelope-from=thomasv1@gmx.de;
helo=mout.gmx.net;
Received: from mout.gmx.net ([212.227.17.21])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1WdEoX-0004Gk-OA
for bitcoin-development@lists.sourceforge.net;
Thu, 24 Apr 2014 08:15:27 +0000
Received: from [192.168.1.27] ([86.73.30.202]) by mail.gmx.com (mrgmx003) with
ESMTPSA (Nemesis) id 0MU1MP-1WUgFy1CTp-00QhwO for
<bitcoin-development@lists.sourceforge.net>;
Thu, 24 Apr 2014 10:15:19 +0200
Message-ID: <5358C816.8020707@gmx.de>
Date: Thu, 24 Apr 2014 10:15:18 +0200
From: Thomas Voegtlin <thomasv1@gmx.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
CC: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
References: <CANEZrP2hbBVGqytmXR1rAcVama4ONnR586Se-Ch=dsxOzy2O4w@mail.gmail.com> <CAE-z3OUMp_uO07+_R_x2yRLbSCzK1J5isbVUYEY3KF4Tx16K2Q@mail.gmail.com> <53581480.5060103@gk2.sk> <201404231944.14256.luke@dashjr.org> <5358B51F.8010202@gmx.de> <CAPg+sBj68d5ZBDZ4uWvQYHMeq=bwTCaMNbwxfWGVL5MPh=7g2g@mail.gmail.com>
<CAAS2fgS1bsp+T94c2D+uzU4aDsux+BRCSHu5zb0Xaz+LCg0xqA@mail.gmail.com>
In-Reply-To: <CAAS2fgS1bsp+T94c2D+uzU4aDsux+BRCSHu5zb0Xaz+LCg0xqA@mail.gmail.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:6La/201e0x2MVwUMRVSM/OVVa/fS+aIValm8x5P2i7HvywdCloA
Hvu2ZkbwZDpxetlDGODTPpMB9wv3JGi2+6gVKzosc2Qg1I6i3xYb65O40tASu9XkRd4KtQF
DN66NmdVrEKXi4CpQPAtxuh3dS+ywuHAk4LWdUw84verugLU3hq60ZCTg83l12K7CKNB9I0
chHzZnbumuRKHf3v2qsag==
X-Spam-Score: -0.0 (/)
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
(thomasv1[at]gmx.de)
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [212.227.17.21 listed in list.dnswl.org]
-0.0 SPF_PASS SPF: sender matches SPF record
0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
digit (thomasv1[at]gmx.de)
1.2 MISSING_HEADERS Missing To: header
X-Headers-End: 1WdEoX-0004Gk-OA
Subject: Re: [Bitcoin-development] New BIP32 structure
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: Thu, 24 Apr 2014 08:15:27 -0000
Le 24/04/2014 09:21, Gregory Maxwell a écrit :
>
> It doesn't appear to me that reoccurring payments, receive accounts,
> multisig addresses, etc can be used with this proposal, but instead
> you must use a different purpose code and another BIP and are not
> compatible with the draft here.
>
> Am I misunderstanding it? Will Electrum be limiting itself in this
> way? I'd consider it a unfortunate loss of functionality if wallets
> couldn't implement reoccurring payment chains without making users
> generate entirely different wallets (which they couldn't share funds
> across) since addresses for recurring payments was one of the main
> motivations in BIP32.
>
>
No, Electrum will not be limiting itself in this way. I believe that we
are only at the beginning of exploring the different possibilities
opened by HD wallets. It will probably take years until we have clear
ideas on what users need, what choices they make, and how to organize
everything. Therefore it is too early to take decisions that might limit
future functionality.
I can see that it is very difficult today to find a consensus on wallet
structure between wallet developers. In addition, I changed my mind
several times on these questions, so I guess I will probably need to
change things again in the future.
This is why I decided to include a version number in Electrum seeds. The
version number will be updated everytime the wallet structure changes. I
know many developers do not follow me on this, but that is something I
am quite sure Electrum needs, despite all the other things I am not sure
about :)
I think it is too early to aim for inter-wallet compatibility today. I
guess we should postpone this goal, and move on with software releases.
As Andreas pointed out, we should just make sure that we do not import
an incompatible seed in another wallet, because not recovering all your
bitcoins would be a terrible user experience; the version number built
in the seed will ensure that for Electrum.
|
