Electrum - State of the Alloy

[ThomasV]

Great to hear that you are working on Electrum fulltime now ThomasV !

As I expect you know, Gary and I are working on an HD compatible version of MultiBit.
Mike is refactoring bitcoinj to add in HD support.

The code is closed alpha at the moment (we will open it once it goes into beta but we are still tinkering at the moment).

I think it would be a good idea if we made sure the HD wallets in Electrum 2.0 and MultiBit HD work seamlessly together. When we get it all working in MultiBit HD would you like to be part of our beta testing ?
And conversely we would also like early access to your code to see if everything hooks up together properly.

Were you planning to support Trezor too ?
If so then we can probably do the same approach there.


Once wallets get created and regular users start putting bitcoin on them it starts getting expensive time and effort wise to rework things. I think it is worth us coordinating to bash our code as thoroughly as possible before it goes out on general release.

Let me know if you'd like to and we can give you access to our repo.

Cheers,

Jim

Thank you, Jim! Is there anything in your code that is not specified in BIP32/BIP39?

As you might know, I postponed BIP32 support in Electrum because we had discussions on the developer's mailing list regarding BIP39, and we could not reach an agreement.
I think the latest BIP39 proposal is much more reasonable, because it does not impose a dictionary.

An important requirement for Electrum is that wallets must be fully recoverable from seed, and with no other knowledge than the seed. This special requirement imposes some constraints on address generation (users cannot generate arbitrary addresses, the wallet creates new addresses when already created addresses are used). The same type of constraint will exist for accounts in a HD wallet with multiple accounts.

Since other wallets do not have that requirement, these constraints are not part of BIP32.
They are, however, important for Electrum wallets.

[jim618]

Hi ThomasV,

We are planning to implement an intentionally 'vanilla' implementation of BIP32/ 39.
In a similar thought process to you (I think) we are only going to have the BIP32 generated addresses in the wallet e.g you won't be able to import vanity addresses. We'll still maintain the old version of MultiBit with the random key wallets for as long as people want but MultiBit HD will just support HD addresses.

For the general user (I use my lovely but not very technical niece as my archetypical user) being able to restore a wallet from the 12 (or 18 or 24) word seed is such a useful thing the restriction is worth putting in.


There is other stuff going in like an improved contacts database etc but for the core wallet behaviour I don't see any reason why Electrum 2.0 and MultiBit HD wallets shouldn't be fully interoperable. I think the user should be able to use either (or both) and all the addresses, change addresses etc should all be generated identically.

I'll get Gary to open up the multibit-hd repo to you. It'll be a while before we integrate Mike's (ongoing) HD refactoring of bitcoinj - we are mainly going through the GUI usecases at the moment.

Edit: Can you let me know your github user please ? Looking at the contributors to spesmilo/ electrum I thought I would see a 'thomas.*' but I cannot find you !

:-)

Jim

[ThomasV]

For the general user (I use my lovely but not very technical niece as my archetypical user) being able to restore a wallet from the 12 (or 18 or 24) word seed is such a useful thing the restriction is worth putting in.

If you want users being able to restore using only the seed, you need to make the search finite, therefore to specify how/when new addresses are generated by the wallet.
BIP32 does not specify that; I asked about it in #bitcoin-dev some time ago, but it was considered as non-relevant.

We could use the same spec for that, but mine is not finalized. I am going to upgrade it in Electrum 2.0.

With a client like Multibit, I believe you would also need to rescan the blockchain when restoring a wallet from seed, which makes the process more complicated.

[ThomasV]

Edit: Can you let me know your github user please ? Looking at the contributors to spesmilo/ electrum I thought I would see a 'thomas.*' but I cannot find you !

I am user ecdsa on github

[Mike Hearn]

With a client like Multibit, I believe you would also need to rescan the blockchain when restoring a wallet from seed, which makes the process more complicated.

Yes. I originally asked for the seed to have a timestamp in the encoding for this reason, but it wasn't done. Oh well. I guess BIP39 is not ideal for anyone

IMHO long term the way to go for wallet backups will be to use the seed/private master key as the key for encrypting actual wallet files as well as deriving keys, e.g. on a cloud backup service. Wallets contain more than keys and over time the metadata will become more important.

For pure-SPV wallets to restore a wallet from the seed does indeed require rescanning the chain from the birthday onwards, then extending the chain and updating Bloom filters as the scan progresses. Complicated indeed. My HD work is progressing nicely though and I started on Bloom filtering support today.

[jim618]

Gary should have given you access to the repo now.

Yes - the rescanning makes things a little more complicated for MBHD. I guess you can do it all in a single call  to a stratum server.

What we plan to do is:

When the user creates a new wallet in MBHD they will get a 12 (or 18 or 24) word seed and also a 'wallet creation day' which will probably just be "today's date as the number of days since the genesis block".

We will ask them to write this down with the seed. There is a page in the 'Create wallet wizard' where they reenter their seed + wallet creation day to check it (like in Electrum).

Then, when the user does a restore of a wallet from the seed we will ask them if they have the 'wallet creation day'. If they do then great we have a quicker sync. If they don't then we will have to sync from the date of the very first HD wallet ever created. That'll be a bit slower but it is tolerable as it is only done once per restore.   We are storing the synced wallet (encrypted) on disk so that we only have to do incremental syncs from then on.

We thought about using a service (say on multibit.org) to look it up but will keep it decentralised initially.

You are right: there is also the size of the address tree to search over - I expect Mike will be working on this. It complicates the bloom filtering as it will probably have to extend dynamically as it sees more transactions.

[jim618]

Oh - just read Mike's reply.

We are also creating (with various trapdoor functions) an encryption key from the seed to use for cloud backup encryption.

That way if the user has their laptop stolen they can:
+ use the seed phrase to regenerate their wallet addresses (basic restore)
+ if they have a cloud backup and "offer it up" to MBHD with their seed phrase it will be able to decrypt it using the calculated encryption key and they will get everything back (contacts, tx notes etc).

[Mitchell]

I can only understand half of what is being said above (no idea what a HD wallet is), but I really like the way you guys talk with each other. It's so polite and, I dunno, how it should be done, I guess, haha. Just wanted to say that and yes, it I know that it sounds strange. But I haven't seen a conversation like that on BitcoinTalk for a while, so this is/was a pleasant change.

[Sonny]

The version 2.0 looks really great.
Really looking forward to it.

[ThirdRenaissance]

I think the latest BIP39 proposal is much more reasonable, because it does not impose a dictionary.

What's the downside of an agreed upon dictionary? Would a dictionary predefined by the standard not guarantee seed interoperability between clients implementing bip39?

[ThomasV]

Oh - just read Mike's reply.

We are also creating (with various trapdoor functions) an encryption key from the seed to use for cloud backup encryption.

That way if the user has their laptop stolen they can:
+ use the seed phrase to regenerate their wallet addresses (basic restore)
+ if they have a cloud backup and "offer it up" to MBHD with their seed phrase it will be able to decrypt it using the calculated encryption key and they will get everything back (contacts, tx notes etc).

Hi, thanks for the github access. I will check it out.

[wiseby]

Hi,

I have a question regarding transition to HD wallets in Electrum
What user experience is going to look like? Say in 3 years from now your user is downloading Electrum client and tries to enter Electrum 1.9 seed in it.

What would happen?

When is the planed cut-off date? I.e. you would probably have "New" and "Old" versions of Electrum published on your website for a while along with instructions for non tech savvy. How long is that "while" going to be?


Another question: I was checking out carbonwallet.com, that is a BUGGY web version of electrum wallet. I have fixed a bug there which allowed users to enter arbitrary words, and working on another bug which seems to be related to the generation of change addresses (they do not show up in carbon).

Is there anything special with how you are generating change addresses in 1.9? Are they any different from normal addresses? Where I can read about this?

P.S. I'm not a developer of carbonwallet and discourage anyone from using it. I have found 2 major bugs in the first day of using it. I'm just fixing them for fun and self education.

[empoweoqwj]

That's fantastic news. I've used Electrum since I first heard about it and not regretted it. Getting funding is totally awesome news, bring on 2.0 !!

[duckinhaxor]

Hi ThomasV,

I don't use electrum yet, I'm currently using armory because it has severals features I need.

However, Armory is not a user friendly, it's uber heavy, slow, and I really don't like to have to store 2 times the blockchain (1 time for bitcoind/-qt and 1 time for armory), I believe storing the blockchain is something to be done server side and not on a client. That's why I think I m going to use a thin client like Electrum in the future (near future I hope). But now, there is no thin client which can do what I want.

Some questions :

- Shamir Shared Secret backup is a very cool feature. Example, I split my seed backup in 3 parts using the shamir alogirthm, and If I want to recover my seed, I only need two parts of the backup to recover the seed. Very good for physical security. Yes I can do it manually using some software, but it would be cool if it could be integrated to Electrum in a noob friendly way so my wife could recover my wallet if something happens to me. Do you plan to implement this feature ?

This special requirement imposes some constraints on address generation (users cannot generate arbitrary addresses, the wallet creates new addresses when already created addresses are used)

- Do you mean I can't generate a new address if I didn't received bitcoin on the previous one ? I don't think it's a good way to handle address generation, a lot of people need to generate multiple addresses for one account in advance, I want to be able to generate 10 different public address for one account without being forced to use them.

- Is Electrum 2 going to be able to handle multiple wallet from one instance ? I know you are going to handle BIP32 wallet or something like that but I would like to be able to open severals differents wallets (and not multiple accounts on one wallet using BIP32 key derivation feature). I would like to be able to look at my watch-only "cold storage" wallet (the one where the private keys is not on the computer) and my others wallets in one instance. Why I don't want to handle all my accounts on one HD Wallet ? Because cold storage is worthless in this case, If one of a child private key is compromised, every private key derivated from the same seed can be recovered (both childs and parents private key) http://bitcoinmagazine.com/8396/deterministic-wallets-advantages-flaw/. That's why it's important to have the cold storage wallet on a different wallet.

[halcyon]

- Shamir Shared Secret backup is a very cool feature. Example, I split my seed backup in 3 parts using the shamir alogirthm, and If I want to recover my seed, I only need two parts of the backup to recover the seed. Very good for physical security. Yes I can do it manually using some software, but it would be cool if it could be integrated to Electrum in a noob friendly way so my wife could recover my wallet if something happens to me. Do you plan to implement this feature ?

fascinating stuff!
In my humble opinion this should really be considered as a feature for future electrum versions.

[FallingKnife]

Congratulations! You have earned the success that is headed your way. Thanks for all you've done for the community.

[KF]

...
I have a question regarding transition to HD wallets in Electrum
What user experience is going to look like? Say in 3 years from now your user is downloading Electrum client and tries to enter Electrum 1.9 seed in it.

What would happen?

When is the planed cut-off date? I.e. you would probably have "New" and "Old" versions of Electrum published on your website for a while along with instructions for non tech savvy. How long is that "while" going to be?
...

+1

How would the implementation of BIP32 (and possibly BIP39) in 2.0 affect the ability to recover old-style wallets? Would there be an option in 2.0+ to specify the legacy deterministic wallet and legacy seed?

Related: Would there be a tool to enable migration of cold storage wallets from the legacy deterministic generator to BIP32?

[Nancarrow]

I'm also very interested in this question. ISTM the best thing to do would be to keep the ability to recognise old wallet seeds and generate old style address blocks indefinitely. Presumably it's just a short python module that can be retained without significantly bloating the code?

[Abdussamad]

How would the implementation of BIP32 (and possibly BIP39) in 2.0 affect the ability to recover old-style wallets?

I'm also very interested in this question. ISTM the best thing to do would be to keep the ability to recognise old wallet seeds and generate old style address blocks indefinitely. Presumably it's just a short python module that can be retained without significantly bloating the code?

pre 2.0 wallet seeds will continue to be supported. They will be recognized by the number of words in the seed:

in version 2.0, the seed phrase will be hashed in order to generate the master public key.
thus, any phrase length will be supported.

However, in order to recognize seeds from version < 2, I plan to check if the number of words is 12.
so it's probably not a good idea to create 24 words seeds now.

[KF]

...
pre 2.0 wallet seeds will continue to be supported. They will be recognized by the number of words in the seed:

in version 2.0, the seed phrase will be hashed in order to generate the master public key.
thus, any phrase length will be supported.

However, in order to recognize seeds from version < 2, I plan to check if the number of words is 12.
so it's probably not a good idea to create 24 words seeds now.

So that means those who created 24 word seeds (by entering raw hex) would have to do a migration of all funds to the new style wallets? However, the legacy seeds will continue to be able to recover a wallet even if BIP39 is implemented? (due to the hashing of the seed)

I highly recommend implementing WarpWallet hashing (with salt) if the purpose of creating the hashed seed phrase is to better support brainwallets.