rich1.0npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydhttps://nostr.ae/npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydnjumphttps://nostr.ae📅 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>