📅 Original date posted:2014-03-12
📝 Original message:On 03/12/2014 04:45 PM, Jean-Paul Kogelman wrote:
> Yes I am. There are some differences between BIP 39 and my proposal though.
>
> - BIP 39 offers an easy list of words, no gnarly string of case sensitive letters and numbers.
Which is better IMO. I can't imagine anyone writing down a long Base58
encoded string.
> - BIP 39 only offers one fixed length of entropy, always 12 words, no option to increase or decrease the length.
Not true, BIP39 supports 12/18/24 words (= 128/192/256 bits of entropy).
> - BIP 39 doesn't have a genesis date field, so no optimization during blockchain rescan.
This is nice addition, indeed. But we needed to limit the data as
possible in order not to increase the number of words needed to be noted
down.
> - BIP 39 doesn't have password typo detection. No easy way to recover a password if you know most of it.
It has a detection. Not correction though.
> - BIP 39 does not have a user selectable KDF, only 2048 round PBKDF2-HMAC-SHA512.
> - BIP 39 can't outsource the KDF computation to a 3rd party.
True, but having one or two solid options are better than having
gazillions of possible options.
> - BIP 39 wallet implementors can use their own word lists, breaking cross wallet compatibility.
True, but they are encouraged to use the list provided. Possibility to
outsource KDF outside of your "standard" breaks much more compatibility
than this.
--
Best Regards / S pozdravom,
Pavol Rusnak <stick at gk2.sk>
Pavol Rusnak [ARCHIVE] /
npub1wc…3hnuq
2023-06-07 15:15:13
in reply to nevent1q…vys7
Author Public Key
npub1wccnjljxnarlx564vuc37hmuzuffurljevjnmuq4u0vjmh7e933sn3hnuqPublished at
2023-06-07 15:15:13Event JSON
{
"id": "00aa4949702cfcc3c7569d02844da7d6f7eb225dec409c588b33200408cf401d",
"pubkey": "7631397e469f47f3535567311f5f7c17129e0ff2cb253df015e3d92ddfd92c63",
"created_at": 1686150913,
"kind": 1,
"tags": [
[
"e",
"e2b06c13dda090fd765a6fae17847c84821995c150a37c86a1dca89140911552",
"",
"root"
],
[
"e",
"4bf869d1e1e16082c5c45e111a5cfdceb680c29a31e87a22b5a30d472c51225f",
"",
"reply"
],
[
"p",
"874fa44d110b2119208ba6fb27607799f16a00c82143201ad7f179a89f0df349"
]
],
"content": "📅 Original date posted:2014-03-12\n📝 Original message:On 03/12/2014 04:45 PM, Jean-Paul Kogelman wrote:\n\u003e Yes I am. There are some differences between BIP 39 and my proposal though. \n\u003e \n\u003e - BIP 39 offers an easy list of words, no gnarly string of case sensitive letters and numbers.\n\nWhich is better IMO. I can't imagine anyone writing down a long Base58\nencoded string.\n\n\u003e - BIP 39 only offers one fixed length of entropy, always 12 words, no option to increase or decrease the length.\n\nNot true, BIP39 supports 12/18/24 words (= 128/192/256 bits of entropy).\n\n\u003e - BIP 39 doesn't have a genesis date field, so no optimization during blockchain rescan.\n\nThis is nice addition, indeed. But we needed to limit the data as\npossible in order not to increase the number of words needed to be noted\ndown.\n\n\u003e - BIP 39 doesn't have password typo detection. No easy way to recover a password if you know most of it.\n\nIt has a detection. Not correction though.\n\n\u003e - BIP 39 does not have a user selectable KDF, only 2048 round PBKDF2-HMAC-SHA512. \n\u003e - BIP 39 can't outsource the KDF computation to a 3rd party.\n\nTrue, but having one or two solid options are better than having\ngazillions of possible options.\n\n\u003e - BIP 39 wallet implementors can use their own word lists, breaking cross wallet compatibility.\n\nTrue, but they are encouraged to use the list provided. Possibility to\noutsource KDF outside of your \"standard\" breaks much more compatibility\nthan this.\n\n-- \nBest Regards / S pozdravom,\n\nPavol Rusnak \u003cstick at gk2.sk\u003e",
"sig": "e27e016bed2fce2b51100b2cf8f3cb0e42db130e51f13f2d950ec16bb2524eff7035c561382faf449c62798a940c67ca4d364712d64422dbe5be1afebdc1d22f"
}