Subject: Re: [Bitcoin-development] New BIP32 structure

From: Thomas Kerin <[email-masked]>
Date: Thu, 27 Mar 2014 13:12:07 +0000

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 <[email-masked]> 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 freedom?
>
>
> On Thu, Mar 27, 2014 at 1:28 PM, Mike Hearn <[email-masked]> 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 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 <[email-masked]> wrote:
>>
>>>
>>>
>>> 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).
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> [email-masked]
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>
>>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> [email-masked]
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>