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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1WdDyU-0004iH-QY
for bitcoin-development@lists.sourceforge.net;
Thu, 24 Apr 2014 07:21:38 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.217.178 as permitted sender)
client-ip=209.85.217.178; envelope-from=gmaxwell@gmail.com;
helo=mail-lb0-f178.google.com;
Received: from mail-lb0-f178.google.com ([209.85.217.178])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WdDyQ-0008J1-Vg
for bitcoin-development@lists.sourceforge.net;
Thu, 24 Apr 2014 07:21:38 +0000
Received: by mail-lb0-f178.google.com with SMTP id s7so1661993lbd.37
for <bitcoin-development@lists.sourceforge.net>;
Thu, 24 Apr 2014 00:21:28 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.112.201.42 with SMTP id jx10mr29334lbc.91.1398324088310;
Thu, 24 Apr 2014 00:21:28 -0700 (PDT)
Received: by 10.112.89.68 with HTTP; Thu, 24 Apr 2014 00:21:28 -0700 (PDT)
In-Reply-To: <CAPg+sBj68d5ZBDZ4uWvQYHMeq=bwTCaMNbwxfWGVL5MPh=7g2g@mail.gmail.com>
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>
Date: Thu, 24 Apr 2014 00:21:28 -0700
Message-ID: <CAAS2fgS1bsp+T94c2D+uzU4aDsux+BRCSHu5zb0Xaz+LCg0xqA@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Pieter Wuille <pieter.wuille@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
(gmaxwell[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: 1WdDyQ-0008J1-Vg
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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 07:21:39 -0000
On Thu, Apr 24, 2014 at 12:10 AM, Pieter Wuille <pieter.wuille@gmail.com> wrote:
> On Thu, Apr 24, 2014 at 8:54 AM, Thomas Voegtlin <thomasv1@gmx.de> wrote:
>>> Why do clients need to use the features in BIP 64? If Electrum doesn't want to
>>> use accounts, [...]
>>
>> To clarify:
>> Electrum plans to have bip32 accounts; Multibit will not, afaik.
>
> To clarify:
> BIP64 has a much stricter definition for accounts than BIP32.
>
> In BIP32, it is not well specified what accounts are used for. They
> can be used for "subwallets", "receive accounts" (as in bitcoind's
> account feature), "recurring payments", part of a chain used as
> multisig addresses, ... determined individually for each index.
>
> In BIP64, they are strictly used for subwallets, and can't be used by
> anything else.
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.
|
