Re: [Bitcoin-development] New BIP32 structure

[Mike Hearn <mike@plan99.net>]

[-- Attachment #1: Type: text/plain, Size: 2560 bytes --]

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 <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 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 é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
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>

[-- Attachment #2: Type: text/html, Size: 3528 bytes --]