Is Electrum 2.6.3 safe to generate keys?

[RealBitcoin]

My friend has generated a wallet on electrum 2.6.3, is it safe to generate seed on that old electrum?

I see that the 2.7.x versions are pretty unstable, since almost every week we get a new patch, and there is no fundamental risk between 2.6.4 and 2.6.3.

So my question is, is the 2.6.3 version safe to generate seeds?

[Quickseller]

You don't actually generate keys in electrum once your wallet has been created.

When you create an electrum wallet, electrum will generate a seed (or you can do this yourself), which electrum will translate to a "xpriv" key, which also has an associated "xpubkey".

When you ask electrum for a new address, it will use the xpubkey to get the "next" Bitcoin address. When you decide that you want to spend some of your Bitcoin, electrum will use the xprivkey to calculate the private key.

All of your addresses and associated private keys are determined at the time you generate your seed. 

[RealBitcoin]

You don't actually generate keys in electrum once your wallet has been created.

When you create an electrum wallet, electrum will generate a seed (or you can do this yourself), which electrum will translate to a "xpriv" key, which also has an associated "xpubkey".

When you ask electrum for a new address, it will use the xpubkey to get the "next" Bitcoin address. When you decide that you want to spend some of your Bitcoin, electrum will use the xprivkey to calculate the private key.

All of your addresses and associated private keys are determined at the time you generate your seed. 

I actually meant to say generate seeds/private keys, so a new wallet is what I am referring to.

My friend asks this since he has created a wallet on 2.6.3 and given that the 2.7.x softwares are pretty unstable, 2.6.3 looks safe.

But we need confirmation if this is so.

[Quickseller]

As I said previously, electrum will not actually generate new private keys, only calculate the private key of a spending address based on your xprivkey, which is based on your seed.

Regarding how safe it is to generate a seed using electrum 2.6.3, it is only safe to the extent that your computer is not compromised

[RealBitcoin]

Regarding how safe it is to generate a seed using electrum 2.6.3, it is only safe to the extent that your computer is not compromised

That is not what I was asking. I was asking, whether the seed generation/wallet creation on 2.6.3  is as safe or safer than on 2.7.x models.

I have seen a lot of modifications how the seed is generated on 2.7.x, so that is why I asking, whether 2.6.3 is safe to generate seeds with.

My friend has a wallet on 2.6.3, and I am curious too, since all these new implementations/features on Electrum since could have compromized the seed generation.

[Quickseller]

I was asking, whether the seed generation/wallet creation on 2.6.3  is as safe or safer than on 2.7.x models.

I am not aware of any seed generation issues with 2.6.3 that was fixed/changed in 2.7.x

The paranoid always have the option of generating a seed outside of electrum

[RealBitcoin]

I was asking, whether the seed generation/wallet creation on 2.6.3  is as safe or safer than on 2.7.x models.

I am not aware of any seed generation issues with 2.6.3 that was fixed/changed in 2.7.x

The paranoid always have the option of generating a seed outside of electrum

Were there any seed generation issues in 2.6.3 in your opinion?

[Coding Enthusiast]

You could have easily gone on GitHub and read the Release-Notes:
https://github.com/spesmilo/electrum/blob/master/RELEASE-NOTES#L1-L115

As you can see there were no issues with seeds generated on 2.6.3

There were some bugs introduced with for example 2.7.5 the utf8 bug for password extended seeds (a new feature in 2.7 versions) which are removed now.

[RealBitcoin]

You could have easily gone on GitHub and read the Release-Notes:
https://github.com/spesmilo/electrum/blob/master/RELEASE-NOTES#L1-L115

As you can see there were no issues with seeds generated on 2.6.3

There were some bugs introduced with for example 2.7.5 the utf8 bug for password extended seeds (a new feature in 2.7 versions) which are removed now.

Ok but has anyone tested it except the main dev, how many people are testing the software for bugs and errors?

[Abdussamad]

You could have easily gone on GitHub and read the Release-Notes:
https://github.com/spesmilo/electrum/blob/master/RELEASE-NOTES#L1-L115

As you can see there were no issues with seeds generated on 2.6.3

There were some bugs introduced with for example 2.7.5 the utf8 bug for password extended seeds (a new feature in 2.7 versions) which are removed now.

Ok but has anyone tested it except the main dev, how many people are testing the software for bugs and errors?

Every single user. However, most don't report bugs (this is the case with all software). The ones that do help improve the software because they bring those bugs to the devs' attention and then they can fix it.

One difference between 2.7 and older versions when it comes to seeds is that in 2.7 they have standardized seed mnemonics to 12 words for all wallet types. In 2.6 it was 13 words for normal wallets and more words for other wallet types. That doesn't make the 2.6.x seeds any more or less safe though.

The other difference is that the wallet file format changed in 2.7.x. So when you install 2.7.x it upgrades your wallets to the new file format. So old wallets can be used in 2.7.x but newer ones can't be used in 2.6.x.

So you can continue to create wallets in 2.6.x if you prefer but I don't recommend it. I suggest creating new wallets using 2.7.x. The release of lots of point versions in the 2.7.x line should not be taken as a bad thing. If anything it shows that the developers' are actively fixing bugs and improving the software and right now at .11 it's pretty mature.

[RealBitcoin]

You could have easily gone on GitHub and read the Release-Notes:
https://github.com/spesmilo/electrum/blob/master/RELEASE-NOTES#L1-L115

As you can see there were no issues with seeds generated on 2.6.3

There were some bugs introduced with for example 2.7.5 the utf8 bug for password extended seeds (a new feature in 2.7 versions) which are removed now.

Ok but has anyone tested it except the main dev, how many people are testing the software for bugs and errors?

Every single user. However, most don't report bugs (this is the case with all software). The ones that do help improve the software because they bring those bugs to the devs' attention and then they can fix it.

One difference between 2.7 and older versions when it comes to seeds is that in 2.7 they have standardized seed mnemonics to 12 words for all wallet types. In 2.6 it was 13 words for normal wallets and more words for other wallet types. That doesn't make the 2.6.x seeds any more or less safe though.

The other difference is that the wallet file format changed in 2.7.x. So when you install 2.7.x it upgrades your wallets to the new file format. So old wallets can be used in 2.7.x but newer ones can't be used in 2.6.x.

So you can continue to create wallets in 2.6.x if you prefer but I don't recommend it. I suggest creating new wallets using 2.7.x. The release of lots of point versions in the 2.7.x line should not be taken as a bad thing. If anything it shows that the developers' are actively fixing bugs and improving the software and right now at .11 it's pretty mature.

What about the make_seed command, do you think that has changed since 2.6.3 ? Or is it safe to generate on 2.6.3 with this command?

[Coding Enthusiast]

Ok but has anyone tested it except the main dev, how many people are testing the software for bugs and errors?

If by "test" you mean using the wallet, e.g installing 2.6.3, transacting bitcoin, updating to newer versions, continue using, report bugs on bitcointalk/reddit/GitHub; then yes a lot of people are doing it.

If by "test" you mean check the code and see if there is any bug in it then there are 6 developers who have more than 50 commits, and a total of 136 contributors to the open source code
ref: https://github.com/spesmilo/electrum/graphs/contributors
and I am sure there has been others who checked the code over the years and would have or already have reported bugs.

What about the make_seed command, do you think that has changed since 2.6.3 ? Or is it safe to generate on 2.6.3 with this command?

GitHub 101

• Go To https://github.com/spesmilo/electrum and search for make_seed or any other things you want to see changed.
• You will end up here: https://github.com/spesmilo/electrum/blob/master/lib/mnemonic.py#L162
• Now look what has changed if you were following Electrum development.
• If not click on history and start reading the changes.
  
• To see which versions the change affects see the Tags
  * I have no python knowledge so you may want to check the links yourself!

[RealBitcoin]

Ok but has anyone tested it except the main dev, how many people are testing the software for bugs and errors?

If by "test" you mean using the wallet, e.g installing 2.6.3, transacting bitcoin, updating to newer versions, continue using, report bugs on bitcointalk/reddit/GitHub; then yes a lot of people are doing it.

If by "test" you mean check the code and see if there is any bug in it then there are 6 developers who have more than 50 commits, and a total of 136 contributors to the open source code
ref: https://github.com/spesmilo/electrum/graphs/contributors
and I am sure there has been others who checked the code over the years and would have or already have reported bugs.

What about the make_seed command, do you think that has changed since 2.6.3 ? Or is it safe to generate on 2.6.3 with this command?

GitHub 101

• Go To https://github.com/spesmilo/electrum and search for make_seed or any other things you want to see changed.
• You will end up here: https://github.com/spesmilo/electrum/blob/master/lib/mnemonic.py#L162
• Now look what has changed if you were following Electrum development.
• If not click on history and start reading the changes.
  
• To see which versions the change affects see the Tags
  * I have no python knowledge so you may want to check the links yourself!
  

OK, I also dont know much about Python, I know C++ but thats about it, I can sort of figure out what the code means.

I have observed this change, that worries me the most (and there were other things that were changed with the seed)

https://github.com/spesmilo/electrum/commit/569a3b4fab68a61db8c0e6f2362728dd5850c3f5

This was introduced in 2.7, and it's a bit worrying.



It looks like the last word of the seed was not generated very well, so this means that pre-2.7 seeds have a bit lower security?

13 word seeds have 143, and if the last word is not generated well that would be only 132.  Now the address has only 128 bit so we have 4 bit extra, but still, given that if people want better security, i think its just good to fix this. But for older seeds, ~2.0 they would have only 121 bit security with a vulnerability of -7 bits, so people who were using the old electrum wallet with 12 words before this was fixed have weaker seeds.


What are your comments about that change?

[btchris]

First off, it's great IMO to seeing people doing code reviews of Electrum, the more eyes the better!

It looks like the last word of the seed was not generated very well, so this means that pre-2.7 seeds have a bit lower security?

In short, pre-2.7 seeds have slightly more entropy, but it probably doesn't matter.

     Prior to Electrum 2.7, Electrum encoded 136* bits of data into 13 or fewer mnemonic words using a wordlist of length 2048**. log₂2048=11, so each word is capable of encoding exactly 11 bits of data. This made Electrum perhaps not as efficient as it could have been, since 13 words (as you already pointed out) can store 143 bits of data, but it only needed 136 bits of storage.

*From the source:

Code:

n_added = max(16, len('01')*4 + 128 - ceil(log2(1)))
n_added = max(16, 2*4 + 128 - 0)
n_added = 136

**Except for the Portuguese word list which has 1626 words in it, log₂1626≈10.67 bits per word.

     Prior to encoding, Electrum truncates any leading 0 bits, so if the 136 bits of data has 4 or more leading 0 bits (1 in 16 chance for random data), the resulting mnemonic would be 12 or fewer words. There's no loss of bit storage/security here, it's simply the equivalent of using a simple compression algorithm before encoding into words.

     These 136 bits are generated randomly by the OS (assuming no OS bugs), but are then incremented until an HMAC of these bits starts with the byte 0x01 to act as a sort of checksum. This effectively discards 255 out of 256 all possible seeds, which decreases the entropy by 8 bits (2⁸=256), resulting in a seed with about 128 bits of entropy.

     AFAIK, all versions of Electrum 2.x prior to 2.7 used this algorithm (assuming custom entropy wasn't added), but I could be mistaken.

     The commit you referenced makes two changes. First, instead of aiming to gather 136 bits from the OS, it aims for just 128 bits. Second, it rounds 128 up to remove the inefficiency I mentioned above so that the mnemonic's max possible length is fully utilized. 128 bits gets rounded up to 132 bits ( ⌈128/log₂2048⌉*log₂2048 ). The result, after removing the bits to account for the checksum, is 124 bits of entropy (≈120 bits for Portuguese).

     The second change makes sense to me, but I don't understand the reasoning behind the first. The commit message says in part "count prefix length as entropy" which I disagree is a valid thing to do.

     Does this commit matter practically? Not really IMO, 124 bits of seed entropy is still far beyond any practical ability to crack any resulting ECDSA keys.

[RealBitcoin]

First off, it's great IMO to seeing people doing code reviews of Electrum, the more eyes the better!

It looks like the last word of the seed was not generated very well, so this means that pre-2.7 seeds have a bit lower security?

In short, pre-2.7 seeds have slightly more entropy, but it probably doesn't matter.

     Prior to Electrum 2.7, Electrum encoded 136* bits of data into 13 or fewer mnemonic words using a wordlist of length 2048**. log₂2048=11, so each word is capable of encoding exactly 11 bits of data. This made Electrum perhaps not as efficient as it could have been, since 13 words (as you already pointed out) can store 143 bits of data, but it only needed 136 bits of storage.

*From the source:

Code:

n_added = max(16, len('01')*4 + 128 - ceil(log2(1)))
n_added = max(16, 2*4 + 128 - 0)
n_added = 136

**Except for the Portuguese word list which has 1626 words in it, log₂1626≈10.67 bits per word.

     Prior to encoding, Electrum truncates any leading 0 bits, so if the 136 bits of data has 4 or more leading 0 bits (1 in 16 chance for random data), the resulting mnemonic would be 12 or fewer words. There's no loss of bit storage/security here, it's simply the equivalent of using a simple compression algorithm before encoding into words.

     These 136 bits are generated randomly by the OS (assuming no OS bugs), but are then incremented until an HMAC of these bits starts with the byte 0x01 to act as a sort of checksum. This effectively discards 255 out of 256 all possible seeds, which decreases the entropy by 8 bits (2⁸=256), resulting in a seed with about 128 bits of entropy.

     AFAIK, all versions of Electrum 2.x prior to 2.7 used this algorithm (assuming custom entropy wasn't added), but I could be mistaken.

     The commit you referenced makes two changes. First, instead of aiming to gather 136 bits from the OS, it aims for just 128 bits. Second, it rounds 128 up to remove the inefficiency I mentioned above so that the mnemonic's max possible length is fully utilized. 128 bits gets rounded up to 132 bits ( ⌈128/log₂2048⌉*log₂2048 ). The result, after removing the bits to account for the checksum, is 124 bits of entropy (≈120 bits for Portuguese).

     The second change makes sense to me, but I don't understand the reasoning behind the first. The commit message says in part "count prefix length as entropy" which I disagree is a valid thing to do.

     Does this commit matter practically? Not really IMO, 124 bits of seed entropy is still far beyond any practical ability to crack any resulting ECDSA keys.

Yeah but not with a quantum computer, since if the public key is not known we have 160 bit of security, so the seed should reflect that for unspent addresses.


Anyway 1 more question:

If you say the pre 2.7 wallets have 13 words but only reflect 12 word security, while the  post 2.7 wallets have 12 words but that is more efficiently done here, then technically the post 2.7 wallet with 13 words is better than pre-2.7 wallet with 13 words.

In fact for maximum security you should use 15 words and unspent addresses.

[shorena]

-snip-
Yeah but not with a quantum computer, since if the public key is not known we have 160 bit of security, so the seed should reflect that for unspent addresses.

QC do not matter against hashes.

[btchris]

If you say the pre 2.7 wallets have 13 words but only reflect 12 word security

Plus a "checksum". Only half the 8-bit checksum (plus the entropy) would fit into 12 words, hence the need for a 13th which encodes just 4 bits. (Note that BIP-39 has a smaller 4-bit overhead for its checksum which does fit into 12 words.)

while the  post 2.7 wallets have 12 words but that is more efficiently done here

Yes, but only more efficient in the sense that there are no words which encode fewer than 11 bits; so better encoding efficiency. Since half of the 8-bit "checksum" wouldn't fit into 12 words, the choice was apparently made to reduce security by 4 bits post-2.7 so that now everything fits into 12.

then technically the post 2.7 wallet with 13 words is better than pre-2.7 wallet with 13 words.

Potentially, but it depends on how you call make_seed().

With post-2.7, calling make_seed() with 133 <= num_bits <= 143 gives you a wallet with 13 words and always 135 bits of security due to the rounding-up-to-improve-encoding-efficiency I mentioned. With pre-2.7, you'd get the exact same security level and word count by calling make_seed() with num_bits == 135.

The difference is that pre-2.7, num_bits was the desired security level you wanted, and could result in a mnemonic with an added word which encodes fewer than 11 bits. Post-2.7 num_bits is now a lower bound for the total number of bits you want to encode in the mnemonic including the "checksum". It's a bit confusing post-2.7 IMO.

Regardless, by default, make_seed() is called with num_bits == 128, which generates a 12-word 124-bit-security mnemonic with post-2.7, and a 13-word 128-bit-security mnemonic with pre-2.7.

In fact for maximum security you should use 15 words and unspent addresses.

To improve security if ECDSA is ever broken (given 160-bit RIPEMD)? I suppose, but practically speaking there are many other far more likely attack vectors, such as side channel attacks against Electrum/Python, the quality of the underlying OS's CSPRNG, the ability to see pubkeys in the mempool prior to being added to a block (bad if ECDSA is broken), etc.

[Kisanaq]

As my experiences, electrum is very recommended and 2.6.3 safe to generate keys. Until now, I was sent some bitcoin with this version and everything is fast, good and full secure

[RealBitcoin]

the ability to see pubkeys in the mempool prior to being added to a block (bad if ECDSA is broken), etc.

Is that concerning though, a transaction should confirm in 24-48 hours. Would a quantum comp be able crack a public key in that amount of time?

I'm no expert but looks like the quantum computers are not that powerful as they sound, please enlighten me.

Potentially, but it depends on how you call make_seed().

With post-2.7, calling make_seed() with 133 <= num_bits <= 143 gives you a wallet with 13 words and always 135 bits of security due to the rounding-up-to-improve-encoding-efficiency I mentioned. With pre-2.7, you'd get the exact same security level and word count by calling make_seed() with num_bits == 135.

The difference is that pre-2.7, num_bits was the desired security level you wanted, and could result in a mnemonic with an added word which encodes fewer than 11 bits. Post-2.7 num_bits is now a lower bound for the total number of bits you want to encode in the mnemonic including the "checksum". It's a bit confusing post-2.7 IMO.

Regardless, by default, make_seed() is called with num_bits == 128, which generates a 12-word 124-bit-security mnemonic with post-2.7, and a 13-word 128-bit-security mnemonic with pre-2.7.

Yes I understand, so its just a question of encoding efficiency. I guess 1 word here and there is no big deal.

[RealBitcoin]

I went through the changes in the code and tracked the more important changes to the seed, and it looks like 2.6.3 and 2.6.4 is still good for making a wallet in my opinion.

I am a bit skeptic about the 2.7.x implementations because there is a lot of changes there suddenly and it would take more time to review them. Apart from making the seed more efficient, I dont see any improvement there in terms of security.

It needs more testing and code review, if somebody has like 100,000 BTC he doesnt want to generate a seed on an untested code lol