Thy Shizzle [ARCHIVE] on Nostr: 📅 Original date posted:2015-03-12 📝 Original message:Right you are! I saw ...
📅 Original date posted:2015-03-12
📝 Original message:Right you are!
I saw Thomas's email about Electrum 2.0 not supporting BIP39.
It seems he had the idea that the wordlist was a strict requirement yet it is not, it is unfortunate that Electrum did not go the route of BIP39. The wordlist is irrelevant and merely used to help build mnemonics.
Also as I've shown, you can work a version into it, I was going to actually propose it to the BIP39 authors but didn't think it was an issue.
I think BIP39 is fantastic.
I think Electrum 2.0 (And everyone) should use BIP39 On 2015-03-11 06:21 PM, Thy Shizzle wrote:
> Hmmmm I don't think it's fair to say that there has been a failure to
> standardise. From what I read earlier among the wallets, mostly it came
> down to if a version was noted and the date. Assuming no date is
> provided, it just means you are scanning the block chain from day 0 for
> transactions right? Hardly a big deal as you will still recover funds right?
Unfortunately there's more incompatibility than just the date issue:
* seed: some follow BIP39, and some roll their own
* HD structure: some follow BIP44, some BIP32 derivation, and some roll
their own
So actually very few wallets are seed-compatible, even ignoring the date
question.
>
> Version right now is irrelevant as there is only one version of BIP39
> currently, probably this will change as 2048 iterations of HMACSHA512
> will likely need to be up scaled in the future, I thought about adding
> one extra word into the mnemonic to signify version, so if you have a 12
> word mnemonic then you have 12 words + 1 word version. Version 1 has no
> extra word, version 2 uses the first word on the list, version 3 uses
> the second word on the wordlist, so on and so forth. Least that's what I
> was thinking of doing if I ever had to record a version, won't effect
> anything because entropy increases in blocks of 3 words so one extra
> word can simply be thrown on the end.
That's a reasonable solution.
>
> So in summary I feel that date can be handled by assuming day 0, and
> version is not an issue yet but may become one and probably it is a good
> idea to think about standardising a version into BIP39, I have
> provided a seed idea for discussion.
>
> I don't think it is quite the doom and gloom I'm reading :)
>
>
> devrandom:
> "I'd like to offer that the best practice for the shared wallet use case
> should be multi-device multi-sig. The mobile has a key, the desktop has
> a key and a third-party security oracle has a third key. The oracle
> would have different security thresholds for countersigning the mobile.
>
> This way you can have the same overall wallet on all devices, but
> different security profiles on different keys.
>
> That said, I do agree that mnemonic phrases should be portable, and find
> it unfortunate that the ecosystem is failing to standardize on phrase
> handling."
--
devrandom / Miron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150312/d1164461/attachment.html>;
📝 Original message:Right you are!
I saw Thomas's email about Electrum 2.0 not supporting BIP39.
It seems he had the idea that the wordlist was a strict requirement yet it is not, it is unfortunate that Electrum did not go the route of BIP39. The wordlist is irrelevant and merely used to help build mnemonics.
Also as I've shown, you can work a version into it, I was going to actually propose it to the BIP39 authors but didn't think it was an issue.
I think BIP39 is fantastic.
I think Electrum 2.0 (And everyone) should use BIP39 On 2015-03-11 06:21 PM, Thy Shizzle wrote:
> Hmmmm I don't think it's fair to say that there has been a failure to
> standardise. From what I read earlier among the wallets, mostly it came
> down to if a version was noted and the date. Assuming no date is
> provided, it just means you are scanning the block chain from day 0 for
> transactions right? Hardly a big deal as you will still recover funds right?
Unfortunately there's more incompatibility than just the date issue:
* seed: some follow BIP39, and some roll their own
* HD structure: some follow BIP44, some BIP32 derivation, and some roll
their own
So actually very few wallets are seed-compatible, even ignoring the date
question.
>
> Version right now is irrelevant as there is only one version of BIP39
> currently, probably this will change as 2048 iterations of HMACSHA512
> will likely need to be up scaled in the future, I thought about adding
> one extra word into the mnemonic to signify version, so if you have a 12
> word mnemonic then you have 12 words + 1 word version. Version 1 has no
> extra word, version 2 uses the first word on the list, version 3 uses
> the second word on the wordlist, so on and so forth. Least that's what I
> was thinking of doing if I ever had to record a version, won't effect
> anything because entropy increases in blocks of 3 words so one extra
> word can simply be thrown on the end.
That's a reasonable solution.
>
> So in summary I feel that date can be handled by assuming day 0, and
> version is not an issue yet but may become one and probably it is a good
> idea to think about standardising a version into BIP39, I have
> provided a seed idea for discussion.
>
> I don't think it is quite the doom and gloom I'm reading :)
>
>
> devrandom:
> "I'd like to offer that the best practice for the shared wallet use case
> should be multi-device multi-sig. The mobile has a key, the desktop has
> a key and a third-party security oracle has a third key. The oracle
> would have different security thresholds for countersigning the mobile.
>
> This way you can have the same overall wallet on all devices, but
> different security profiles on different keys.
>
> That said, I do agree that mnemonic phrases should be portable, and find
> it unfortunate that the ecosystem is failing to standardize on phrase
> handling."
--
devrandom / Miron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150312/d1164461/attachment.html>;