Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 74.125.82.43 as permitted sender)
	client-ip=74.125.82.43; envelope-from=thomas.kerin@gmail.com;
	helo=mail-wg0-f43.google.com; 
MIME-Version: 1.0
In-Reply-To: <CANEZrP21X_Uk+_XWN6y2tgiup07Xd12bZZoFfnheG_Lz-ipbPQ@mail.gmail.com>
References: <CANEZrP2hbBVGqytmXR1rAcVama4ONnR586Se-Ch=dsxOzy2O4w@mail.gmail.com>
	<53340999.807@gmx.de>
	<CAJna-HhmFya+3W67qQt0wMhW=B4vJvwdkr-5WnU+KEaKq7uaUA@mail.gmail.com>
	<5334144A.9040600@gmx.de>
	<CANEZrP37dO53Jp2rXpPqO3eMd6AWamtXaReq0arMfC=uY2aFUA@mail.gmail.com>
	<CANEZrP21X_Uk+_XWN6y2tgiup07Xd12bZZoFfnheG_Lz-ipbPQ@mail.gmail.com>
Date: Thu, 27 Mar 2014 13:12:07 +0000
Message-ID: <CAHv+tb5gYKEtbwxwwBGWk-M98kGnjGw3ffNQAaLQz=hb8BTaDg@mail.gmail.com>
From: Thomas Kerin <thomas.kerin@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=f46d043894cf05269104f59655bd
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] New BIP32 structure
Precedence: list

--f46d043894cf05269104f59655bd
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Isn't the length of the seed arbitrary anyway? Once decoded using whatever
mnemonic implementation (electrums, or BIP0039) the bytestream is
immediately passed to HMAC-SHA256 to generate the master key. No matter
what your initial entropy is, it would be hashed anyway.


On Thu, Mar 27, 2014 at 12:49 PM, Mike Hearn <mike@plan99.net> wrote:

> Ah, BIP32 allows for a range of entropy sizes and it so happens that they
> picked 256 bits instead of 128 bits.
>
> I'd have thought that there is a right answer for this. 2^128 should not
> be brute forceable, and longer sizes have a cost in terms of making the
> seeds harder to write down on paper. So should this be a degree of freedo=
m?
>
>
> On Thu, Mar 27, 2014 at 1:28 PM, Mike Hearn <mike@plan99.net> wrote:
>
>> 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 th=
e
>> 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 =E9crit :
>>> > 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 seriou=
s
>>> > 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 addresse=
s
>>> 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 wan=
t
>>> :) 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
>>>
>>
>>
>
>
> -------------------------------------------------------------------------=
-----
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

--f46d043894cf05269104f59655bd
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Isn&#39;t the length of the seed arbitrary anyway? On=
ce decoded using whatever mnemonic implementation (electrums, or BIP0039) t=
he bytestream is immediately passed to HMAC-SHA256 to generate the master k=
ey. No matter what your initial entropy is, it would be hashed anyway.<br>
</div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">O=
n Thu, Mar 27, 2014 at 12:49 PM, Mike Hearn <span dir=3D"ltr">&lt;<a href=
=3D"mailto:mike@plan99.net" target=3D"_blank">mike@plan99.net</a>&gt;</span=
> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">Ah, BIP32 allows for a rang=
e of entropy sizes and it so happens that they picked 256 bits instead of 1=
28 bits.<div>
<br></div><div>I&#39;d have thought that there is a right answer for this. =
2^128 should not be brute forceable, and longer sizes have a cost in terms =
of making the seeds harder to write down on paper. So should this be a degr=
ee of freedom?</div>

</div><div class=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmail_extra"><b=
r><br><div class=3D"gmail_quote">On Thu, Mar 27, 2014 at 1:28 PM, Mike Hear=
n <span dir=3D"ltr">&lt;<a href=3D"mailto:mike@plan99.net" target=3D"_blank=
">mike@plan99.net</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div dir=3D"ltr">By the way, I just noticed that <a href=3D"http://greenadd=
ress.it" target=3D"_blank">greenaddress.it</a> is creating seeds that have =
24 words instead of 12. Does anyone know what&#39;s up with that? They clai=
m to be using BIP32 wallets so I wanted to see if they were using the defau=
lt structure and if so, whether bitcoinj was compatible with it (before I s=
witch to the one discussed here). But it seems we fall at the first hurdle =
...</div>

<div><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 =E9crit :<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><div><br>
<br>
---------------------------------------------------------------------------=
---<br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@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>
</div></div></blockquote></div><br></div>
</div></div><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>
<br></blockquote></div><br></div>

--f46d043894cf05269104f59655bd--