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; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
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
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
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] New BIP32 structure
Precedence: list

--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--