Mike Hearn [ARCHIVE] on Nostr: 📅 Original date posted:2014-03-27 📝 Original message:Obviously, SHA256 can't ...

📅 Original date posted:2014-03-27
📝 Original message:Obviously, SHA256 can't magically generate more entropy out of nothing, it
just stretches whatever is put in. If your seed was only 32 bits then
hashing wouldn't save you: every possible private key could easily be
calculated in advance.


On Thu, Mar 27, 2014 at 2:12 PM, Thomas Kerin <thomas.kerin at gmail.com>wrote:

> 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 at 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 <mike at 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 at 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 at lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>>
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140327/2c5954bd/attachment.html>;