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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <thomasv1@gmx.de>) id 1WdEIo-000745-Ik
for bitcoin-development@lists.sourceforge.net;
Thu, 24 Apr 2014 07:42:38 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmx.de
designates 212.227.17.20 as permitted sender)
client-ip=212.227.17.20; envelope-from=thomasv1@gmx.de;
helo=mout.gmx.net;
Received: from mout.gmx.net ([212.227.17.20])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1WdEIn-0005cU-9h
for bitcoin-development@lists.sourceforge.net;
Thu, 24 Apr 2014 07:42:38 +0000
Received: from [192.168.1.27] ([86.73.30.202]) by mail.gmx.com (mrgmx002) with
ESMTPSA (Nemesis) id 0MHoC5-1WcQ1L3Q7B-003d04 for
<bitcoin-development@lists.sourceforge.net>;
Thu, 24 Apr 2014 09:42:30 +0200
Message-ID: <5358C066.3020500@gmx.de>
Date: Thu, 24 Apr 2014 09:42:30 +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
To: 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>
In-Reply-To: <CAPg+sBj68d5ZBDZ4uWvQYHMeq=bwTCaMNbwxfWGVL5MPh=7g2g@mail.gmail.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:lRIpUMpNTthFHopI1U2ax9cGFW1u9yfpZh+c2OFnf8TjzyDpzeM
f7z4OUiQXV+Z3AMcMgW++ey2ChMCLqbCg5uQLpSJBrEvVwcDPftZsYXxtQpzectJpzIHuC1
ne67L8bF97MKcokYdka5QJ/SHBLn+72ppYrjaR/Ukx4aI8bXYxihgKxB0WeYDnyQ2wVC1HG
aIpCct2Ii6MuPu1OFh0BQ==
X-Spam-Score: -1.2 (-)
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.20 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)
X-Headers-End: 1WdEIn-0005cU-9h
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:42:38 -0000
Le 24/04/2014 09:10, Pieter Wuille a écrit :
> 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.
>
yes, I saw that.
In particular, bip64 stipulates that the wallet "never mixes coins
across different accounts". This is not what Electrum does currently.
The UI allows you to chose between two modes: activate a single account
(and the wallet will only use UTXOs from that acccount), or activate all
accounts (and spend from all of them simultaneously).
Concerning multisig addresses, I have changed my mind: Electrum will use
parallel BIP32 trees. A wallet will not mix standard and multisig
accounts. I think that is better in terms of UX.
I agree with Mike Hearn's view that wallets with multiple accounts are
probably too difficult to deal with for most users. If a user feels the
need to have different "accounting identities", they will probably
create different wallet files, instead of creating bip32 subwallets.
However, since multiple subwallets have been asked by many users,
Electrum will propose them. But this should not be the default. More
important, multiple accounts should never be required (in my previous
implementation, they were required for multisig, because the wallet was
creating multisig addresses in dedicated multisig accounts)
Thomas
|
