Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WTA6R-0005sn-SD for bitcoin-development@lists.sourceforge.net; Thu, 27 Mar 2014 13:12:15 +0000 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; Received: from mail-wg0-f43.google.com ([74.125.82.43]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WTA6P-0000GU-IW for bitcoin-development@lists.sourceforge.net; Thu, 27 Mar 2014 13:12:15 +0000 Received: by mail-wg0-f43.google.com with SMTP id x13so2489572wgg.14 for ; Thu, 27 Mar 2014 06:12:07 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.77.200 with SMTP id u8mr5051534wiw.48.1395925927141; Thu, 27 Mar 2014 06:12:07 -0700 (PDT) Received: by 10.216.78.5 with HTTP; Thu, 27 Mar 2014 06:12:07 -0700 (PDT) In-Reply-To: References: <53340999.807@gmx.de> <5334144A.9040600@gmx.de> Date: Thu, 27 Mar 2014 13:12:07 +0000 Message-ID: From: Thomas Kerin To: Mike Hearn Content-Type: multipart/alternative; boundary=f46d043894cf05269104f59655bd X-Spam-Score: -0.6 (/) 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 (thomas.kerin[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 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: 1WTA6P-0000GU-IW Cc: Bitcoin Development Subject: Re: [Bitcoin-development] New BIP32 structure X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 13:12:16 -0000 --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 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 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 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
Isn'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.


O= n Thu, Mar 27, 2014 at 12:49 PM, Mike Hearn <mike@plan99.net> wrote:
Ah, BIP32 allows for a rang= e of entropy sizes and it so happens that they picked 256 bits instead of 1= 28 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 degr= ee of freedom?

On Thu, Mar 27, 2014 at 1:28 PM, Mike Hear= n <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 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 = ...


On Thu, Mar 2= 7, 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 softwa= re
> 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 unu= sed
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 "numbe= r of unused
addresses available", so I think we should just give them what they wa= nt
:) 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-de= velopment



-----------------------------------------------------------= -------------------

_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--f46d043894cf05269104f59655bd--