{"type":"rich","version":"1.0","author_name":"npub10f96gqrsu4qpygfgvuvzce47aavjvql703egfde0l2hua8dzpszs67ej47","author_url":"https://nostr.ae/npub10f96gqrsu4qpygfgvuvzce47aavjvql703egfde0l2hua8dzpszs67ej47","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-03-27\n📝 Original message:Le 27/03/2014 13:49, Mike Hearn a écrit :\n\u003e Ah, BIP32 allows for a range of entropy sizes and it so happens that\n\u003e they 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\n\nHere is what I understand:\n\n2^128 iterations is not brute forcable today, and will not be for the \nforeseeable future.\n\nAn EC pubkey of length n can be forced in approximately 2^(n/2) \niterations (see http://ecc-challenge.info/) Thus, Bitcoin pubkeys, which \nare 256 bits, would require 2^128 iterations. This is why unused \naddresses (160 bits hash) are better protected than already used ones.\n\nHowever, people tend to believe that a public key of size n requires 2^n \niterations. This belief might have been spread by this popular image:\nhttps://bitcointalk.org/index.php?topic=508880.msg5616146#msg5616146"}