📅 Original date posted:2014-03-27
📝 Original message: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/1de2fe0e/attachment.html>;
Thomas Kerin [ARCHIVE] /
npub1e4…nt5am
2023-06-07 15:16:22
in reply to nevent1q…j2eu
Author Public Key
npub1e4azew50kk9xzvfpqxzlyftkjt6kken0kf9lnncpdj524f9y4cqsfnt5amPublished at
2023-06-07 15:16:22Event JSON
{
"id": "5115d2db9b53789ec2a7d427dad16ae0b8a6afc437b9613dcfef7fae72408ae1",
"pubkey": "cd7a2cba8fb58a6131210185f2257692f56b666fb24bf9cf016ca8aaa4a4ae01",
"created_at": 1686150982,
"kind": 1,
"tags": [
[
"e",
"d9ddea79394f356d989e65ab112610cc90e9929cf3c160da3cfe266aeba22200",
"",
"root"
],
[
"e",
"870435b6636d7ed6e520ccf43dd99189728d5e55600898c87023d7abb1df5002",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "📅 Original date posted:2014-03-27\n📝 Original message:Isn't the length of the seed arbitrary anyway? Once decoded using whatever\nmnemonic implementation (electrums, or BIP0039) the bytestream is\nimmediately passed to HMAC-SHA256 to generate the master key. No matter\nwhat your initial entropy is, it would be hashed anyway.\n\n\nOn Thu, Mar 27, 2014 at 12:49 PM, Mike Hearn \u003cmike at plan99.net\u003e wrote:\n\n\u003e Ah, BIP32 allows for a range of entropy sizes and it so happens that they\n\u003e picked 256 bits instead of 128 bits.\n\u003e\n\u003e I'd have thought that there is a right answer for this. 2^128 should not\n\u003e be brute forceable, and longer sizes have a cost in terms of making the\n\u003e seeds harder to write down on paper. So should this be a degree of freedom?\n\u003e\n\u003e\n\u003e On Thu, Mar 27, 2014 at 1:28 PM, Mike Hearn \u003cmike at plan99.net\u003e wrote:\n\u003e\n\u003e\u003e By the way, I just noticed that greenaddress.it is creating seeds that\n\u003e\u003e have 24 words instead of 12. Does anyone know what's up with that? They\n\u003e\u003e claim to be using BIP32 wallets so I wanted to see if they were using the\n\u003e\u003e default structure and if so, whether bitcoinj was compatible with it\n\u003e\u003e (before I switch to the one discussed here). But it seems we fall at the\n\u003e\u003e first hurdle ...\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e On Thu, Mar 27, 2014 at 1:06 PM, Thomas Voegtlin \u003cthomasv1 at gmx.de\u003e wrote:\n\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e Le 27/03/2014 12:30, Marek Palatinus a écrit :\n\u003e\u003e\u003e \u003e Ah, I forget to two things, which should be into the BIP as well:\n\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e \u003e a) Gap factor for addresses; as Thomas mentioned, although some\n\u003e\u003e\u003e software\n\u003e\u003e\u003e \u003e can watch almost unlimited amount of unused addresses, this is serious\n\u003e\u003e\u003e \u003e concern for lightweight or server-based wallets like Electrum or\n\u003e\u003e\u003e \u003e myTREZOR. myTREZOR currently uses gap factor 10, which is (from my\n\u003e\u003e\u003e \u003e experience so far) quite sane for most of users.\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e Yes, I was planning to increase the number of available unused addresses\n\u003e\u003e\u003e to 10 or 20 in the bip32 version of Electrum.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Related to this, here is another idea I would like to submit:\n\u003e\u003e\u003e\n\u003e\u003e\u003e Instead of using a \"gap limit\" (maximal number of consecutive unused\n\u003e\u003e\u003e addresses), I think we should get rid of the topology, and simply count\n\u003e\u003e\u003e the number of unused addresses since the beginning of the sequence.\n\u003e\u003e\u003e Indeed, the topology of the sequence of addresses is of no interest to\n\u003e\u003e\u003e the user. Users often misinterpret \"gap limit\" as the \"number of unused\n\u003e\u003e\u003e addresses available\", so I think we should just give them what they want\n\u003e\u003e\u003e :) This is easier to understand, and it makes things more predictable,\n\u003e\u003e\u003e because the wallet will always display the same number of unused\n\u003e\u003e\u003e addresses (except when it is waiting for confirmations).\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e ------------------------------------------------------------------------------\n\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e Bitcoin-development mailing list\n\u003e\u003e\u003e Bitcoin-development at lists.sourceforge.net\n\u003e\u003e\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140327/1de2fe0e/attachment.html\u003e",
"sig": "97370a47c9148633874a7a5f1e4f525a8f54daee5aca19e83b799fb6de3055083a29b413a59483943a5a3caef725da50abaf4c80750d669a79bb740362889bcb"
}