summaryrefslogtreecommitdiff
path: root/38/98ceb3df405c2cfb794de292af675532ad581e
blob: c5484538c43b0d8486ed4f631c584881c0e15d10 (plain)
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
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mh.in.england@gmail.com>) id 1WT9QV-0001AE-IQ
	for bitcoin-development@lists.sourceforge.net;
	Thu, 27 Mar 2014 12:28:55 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.214.172 as permitted sender)
	client-ip=209.85.214.172; envelope-from=mh.in.england@gmail.com;
	helo=mail-ob0-f172.google.com; 
Received: from mail-ob0-f172.google.com ([209.85.214.172])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1WT9QU-0006nz-Fy
	for bitcoin-development@lists.sourceforge.net;
	Thu, 27 Mar 2014 12:28:55 +0000
Received: by mail-ob0-f172.google.com with SMTP id wm4so4173513obc.17
	for <bitcoin-development@lists.sourceforge.net>;
	Thu, 27 Mar 2014 05:28:49 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.92.231 with SMTP id cp7mr310384obb.82.1395923329097;
	Thu, 27 Mar 2014 05:28:49 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.71.231 with HTTP; Thu, 27 Mar 2014 05:28:49 -0700 (PDT)
In-Reply-To: <5334144A.9040600@gmx.de>
References: <CANEZrP2hbBVGqytmXR1rAcVama4ONnR586Se-Ch=dsxOzy2O4w@mail.gmail.com>
	<53340999.807@gmx.de>
	<CAJna-HhmFya+3W67qQt0wMhW=B4vJvwdkr-5WnU+KEaKq7uaUA@mail.gmail.com>
	<5334144A.9040600@gmx.de>
Date: Thu, 27 Mar 2014 13:28:49 +0100
X-Google-Sender-Auth: ACr7s1MNWKxbrFGXZ9sYvCbiGbU
Message-ID: <CANEZrP37dO53Jp2rXpPqO3eMd6AWamtXaReq0arMfC=uY2aFUA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Thomas Voegtlin <thomasv1@gmx.de>
Content-Type: multipart/alternative; boundary=001a11c302cc2a284f04f595ba36
X-Spam-Score: -0.5 (/)
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
	(mh.in.england[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	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: 1WT9QU-0006nz-Fy
Cc: Bitcoin Development <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, 27 Mar 2014 12:28:55 -0000

--001a11c302cc2a284f04f595ba36
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

By the way, I just noticed that greenaddress.it is creating seeds that have
24 words instead of 12. Does anyone know what's up with that? They claim to
be using BIP32 wallets so I wanted to see if they were using the default
structure and if so, whether bitcoinj was compatible with it (before I
switch to the one discussed here). But it seems we fall at the first hurdle
...


On Thu, Mar 27, 2014 at 1:06 PM, Thomas Voegtlin <thomasv1@gmx.de> wrote:

>
>
> Le 27/03/2014 12:30, Marek Palatinus a =C3=A9crit :
> > Ah, I forget to two things, which should be into the BIP as well:
> >
> > a) Gap factor for addresses; as Thomas mentioned, although some softwar=
e
> > 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).
>
>
>
> -------------------------------------------------------------------------=
-----
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

--001a11c302cc2a284f04f595ba36
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">By the way, I just noticed that <a href=3D"http://greenadd=
ress.it">greenaddress.it</a> is creating seeds that have 24 words instead o=
f 12. Does anyone know what&#39;s up with that? They claim to be using BIP3=
2 wallets so I wanted to see if they were using the default structure and i=
f so, whether bitcoinj was compatible with it (before I switch to the one d=
iscussed here). But it seems we fall at the first hurdle ...</div>
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Thu, Mar 2=
7, 2014 at 1:06 PM, Thomas Voegtlin <span dir=3D"ltr">&lt;<a href=3D"mailto=
:thomasv1@gmx.de" target=3D"_blank">thomasv1@gmx.de</a>&gt;</span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex">
<br>
<br>
Le 27/03/2014 12:30, Marek Palatinus a =C3=A9crit :<br>
&gt; Ah, I forget to two things, which should be into the BIP as well:<br>
&gt;<br>
&gt; a) Gap factor for addresses; as Thomas mentioned, although some softwa=
re<br>
&gt; can watch almost unlimited amount of unused addresses, this is serious=
<br>
&gt; concern for lightweight or server-based wallets like Electrum or<br>
&gt; myTREZOR. myTREZOR currently uses gap factor 10, which is (from my<br>
&gt; experience so far) quite sane for most of users.<br>
<br>
<br>
Yes, I was planning to increase the number of available unused addresses<br=
>
to 10 or 20 in the bip32 version of Electrum.<br>
<br>
Related to this, here is another idea I would like to submit:<br>
<br>
Instead of using a &quot;gap limit&quot; (maximal number of consecutive unu=
sed<br>
addresses), I think we should get rid of the topology, and simply count<br>
the number of unused addresses since the beginning of the sequence.<br>
Indeed, the topology of the sequence of addresses is of no interest to<br>
the user. Users often misinterpret &quot;gap limit&quot; as the &quot;numbe=
r of unused<br>
addresses available&quot;, so I think we should just give them what they wa=
nt<br>
:) This is easier to understand, and it makes things more predictable,<br>
because the wallet will always display the same number of unused<br>
addresses (except when it is waiting for confirmations).<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
---------------------------------------------------------------------------=
---<br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</div></div></blockquote></div><br></div>

--001a11c302cc2a284f04f595ba36--