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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <thomasv1@gmx.de>) id 1WT950-00008d-Lh
for bitcoin-development@lists.sourceforge.net;
Thu, 27 Mar 2014 12:06:42 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmx.de
designates 212.227.15.19 as permitted sender)
client-ip=212.227.15.19; envelope-from=thomasv1@gmx.de;
helo=mout.gmx.net;
Received: from mout.gmx.net ([212.227.15.19])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES128-SHA:128)
(Exim 4.76) id 1WT94z-00011t-Nd
for bitcoin-development@lists.sourceforge.net;
Thu, 27 Mar 2014 12:06:42 +0000
Received: from [192.168.1.27] ([84.101.32.222]) by mail.gmx.com (mrgmx001)
with ESMTPSA (Nemesis) id 0M3RVA-1XK9Gs2js8-00r0yx for
<bitcoin-development@lists.sourceforge.net>;
Thu, 27 Mar 2014 13:06:34 +0100
Message-ID: <5334144A.9040600@gmx.de>
Date: Thu, 27 Mar 2014 13:06:34 +0100
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 Development <bitcoin-development@lists.sourceforge.net>
References: <CANEZrP2hbBVGqytmXR1rAcVama4ONnR586Se-Ch=dsxOzy2O4w@mail.gmail.com>
<53340999.807@gmx.de>
<CAJna-HhmFya+3W67qQt0wMhW=B4vJvwdkr-5WnU+KEaKq7uaUA@mail.gmail.com>
In-Reply-To: <CAJna-HhmFya+3W67qQt0wMhW=B4vJvwdkr-5WnU+KEaKq7uaUA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:uLiMYryku5sQ3dXOA94jwroK8TUqQTqkP/DGm8EyxZHSD2tfAkz
GN0YDkU8tdr7KtKSO4OxM0PYCHkoTGlZX6US+pqVQG31j+R7+Ziytcszmt50DJq8BN6HRZR
9AoSVW7m/viYJHNFschk8gmdPQI4Oc2eUVxpcN/mh9IBkaAKrELqsdUxFYz8CkO6304eMBI
z+3jo7/hv0NrOmI3f/yaw==
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.15.19 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: 1WT94z-00011t-Nd
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, 27 Mar 2014 12:06:42 -0000
Le 27/03/2014 12:30, Marek Palatinus a écrit :
> Ah, I forget to two things, which should be into the BIP as well:
>
> a) Gap factor for addresses; as Thomas mentioned, although some software
> can watch almost unlimited amount of unused addresses, this is serious
> concern for lightweight or server-based wallets like Electrum or
> myTREZOR. myTREZOR currently uses gap factor 10, which is (from my
> experience so far) quite sane for most of users.
Yes, I was planning to increase the number of available unused addresses
to 10 or 20 in the bip32 version of Electrum.
Related to this, here is another idea I would like to submit:
Instead of using a "gap limit" (maximal number of consecutive unused
addresses), I think we should get rid of the topology, and simply count
the number of unused addresses since the beginning of the sequence.
Indeed, the topology of the sequence of addresses is of no interest to
the user. Users often misinterpret "gap limit" as the "number of unused
addresses available", so I think we should just give them what they want
:) This is easier to understand, and it makes things more predictable,
because the wallet will always display the same number of unused
addresses (except when it is waiting for confirmations).
|
