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 <m...@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 freedom? > > > On Thu, Mar 27, 2014 at 1:28 PM, Mike Hearn <m...@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 <thoma...@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 >>> >> >> > > > ------------------------------------------------------------------------------ > > _______________________________________________ > 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
