[Bitcoin-development] Electrum 2.0 has been tagged

Jim jim618 at fastmail.co.uk
Wed Mar 11 19:04:37 UTC 2015

The wallet words system isn't perfect for sure but it does help the user in two main ways:
1) Assuming wallet devs ensure forward compatibility for _their_ wallet the user knows they can recover their bitcoins using the same wallet software in case of a Bad Thing Happening.
2) To an imperfect degree, they can transfer/ recover their bitcoins that are stored in Wallet X into Wallet Y. We need to give them guidance on how to do this.

I think it is up to each wallet team to explain to their users clearly how they can do this in their help. It's only good manners to show your guests where the fire exits are.

It can be a simple help page saying:
"If you want to transfer your bitcoin out of MultiBit HD to Lighthouse, do this, this and this.
If you want to use the Trezor wallet you created in MultiBit HD on myTrezor.com, do this, this and this."

That way users have clear instructions on how to recover their bitcoins.
Users don't care about BIP this or BIP that but they REALLY DO CARE about keeping their bitcoins.


On Wed, Mar 11, 2015, at 05:14 PM, Mike Hearn wrote:
> Sigh. The wallet words system is turning into kind of a mess.
> I thought the word list is in fact not a fixed part of the spec, because
> the entropy is a hash of the words. But perhaps I'm misunderstanding
> something.
> The main problem regular SPV wallets have with BIP39 is that there is no
> birth time included in the data. Therefore we must ask users to write down
> a timestamp as well, so we know where to start rescanning the chain. It
> sounds like the Electrum version doesn't fix this, so now we have at least
> FIVE incompatible results from a 12 word list:
>    - Electrum v2 with a version number but no date
>    - myTREZOR with no version and no date and BIP44 key derivation. Some
>    seeds I believe are now being generated with 24 words instead of 12.
>    - MultiBit HD with no version and a date in a custom form that creates
>    non-date-like codes you are expected to write down. I think BIP32 and BIP44
>    are both supported (sorta).
>    - GreenAddress with no version, no date and BIP32
>    - Other bitcoinj based wallets, with no version and a date written down
>    in normal human form, BIP32 only.
> I really hope we can recover from this somehow because otherwise all
> wallets will have to provide the user with a complicated matrix of
> possibilities and software combinations, and in practice many won't bother
> so these word combinations will actually end up being wallet specific for
> no particularly good reason, just very minor details like the presence or
> absence of single fields.
> It feels like we somehow fell flat on our faces just before the finishing
> line. This is deeply unfortunate. Compatibility and UX consistency is
> important!
> Currently, I don't have any bright ideas for how to get everyone back onto
> the same page with a fully compatible system that is acceptable to all. If
> anyone else has suggestions, I'm all ears.
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the 
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

More information about the bitcoin-dev mailing list