Adding the thirteenth word to the existing seed phrase?

[Aikido]

Hello.
I have electrum seed phrase witn some bitcoins.
I want to create new eclectrum wallet with same seed phrase and add thirteenth word at the time of setting up the new electrum wallet.
To move all the funds from the old seed phrase (wallet) to the new one (same seed + 13 word).
Is it safe? Are there any possible errors?

[ranochigo]

Yes it is safe. I would argue that the best practice is to keep the first 12 words safe as well, though not such a huge risk if the 13th word is  complex and long enough. You should keep the entire seed safe, losing the last word can potentially mean losing everything as it is not covered by a checksum.

[Aikido]

Yes it is safe. I would argue that the best practice is to keep the first 12 words safe as well, though not such a huge risk if the 13th word is  complex and long enough. You should keep the entire seed safe, losing the last word can potentially mean losing everything as it is not covered by a checksum.

Thanks for the reply.
The last question that interests me.
13 word can be absolutely anything? Not from the BIP39 list ?

[ranochigo]

Thanks for the reply.
The last question that interests me.
13 word can be absolutely anything? Not from the BIP39 list ?

That is correct. Electrum doesn't follow BIP39 standards, though they use the same wordlist for convenience sake, they are not interchangable though. The entropy is used to determine the mnemonics, which is the 12 words given to you. That is the sole purpose of the wordlist. There is thus no point restricting the passphrase (aka. 13th word) at all, Electrum also doesn't restrict the length (IIRC).

[ABCbits]

Electrum doesn't follow BIP39 standards

This part is important. It means you only can recover your wallet using Electrum and other software which support Electrum standard (formally called Electrum Seed Version System).

Electrum also doesn't restrict the length (IIRC).

Correct, i just tried 500+ character as 13th word and it works.

[o_e_l_e_o]

13 word can be absolutely anything? Not from the BIP39 list ?

Not only not from the BIP39 list, but it doesn't even have to be a word. You can use an entire phrase or sentence (but don't choose a famous quote or song lyric, since you decrease your security by doing so), you can use numbers and characters, you could use something that looks like this: ]$wQ^;g2q94@$HRY

Just make sure you write down your passphrase on paper the same as you (hopefully!) did with your seed phrase when you first set it up, and keep it safe and secure. You want to store your seed phrase and your passphrase back ups separately, so if one is compromised by an attacker they still cannot steal your coins.

Correct, i just tried 500+ character as 13th word and it works.

I did this a few a years ago:

As a quick test, I just created and then recovered an Electrum wallet with a passphrase of 20,000 characters.

Perhaps just a touch excessive.

[HCP]

To move all the funds from the old seed phrase (wallet) to the new one (same seed + 13 word).
Is it safe? Are there any possible errors?

When moving the funds, it is no more "dangerous" or error-prone than any other transaction you are likely to make.

The only real "danger" comes from forgetting your "13th word" if you should ever need to attempt to recover the wallet.

Note that you should not keep the "13th word" backup with your 12 word backup. Otherwise it kind of defeats a lot of the purpose of having a 13th word.

[pooya87]

Perhaps just a touch excessive.

Not just excessive but pointless. Since salt will have 4 bytes appended to its end and then hashed using SHA512 then having anything bigger than 60 bytes is completely pointless.

In other words whether you are using 1 byte passphrase (assuming each char is 1 byte) or 20000 bytes they are both hashed to the same 64 byte result and the attacker could simply skip attacking the passphrase and move to the next step meaning they don't need to check a byte[20000] as their input, they simply skip the initial HMACSHA512 in PBKDF2 and check the byte[64] instead or completely skip BIP39/Electrum mnemonic key derivation and attack the BIP32 itself by using a byte[64] input.
(it goes without saying that it is not possible to brute force byte[64] which is 2⁵¹²).

[o_e_l_e_o]

Surely, technically speaking, anything longer than 128 bits isn't adding any additional security since it would no longer be the weakest link in your set up, assuming an attacker doesn't have partial knowledge of your passphrase with which to reduce the search space?

The obvious scenario where someone would (and should) use more than 60 characters in their passphrase is if their passphrase is not randomly generated like the example I gave above - ]$wQ^;g2q94@$HRY. If you choose dictionary words, names, places, quotes, words from a book/movie/song/poem/etc. as your passphrase, then 60 characters will result in far less than 60 bytes of entropy.

[pooya87]

The obvious scenario where someone would (and should) use more than 60 characters in their passphrase is if their passphrase is not randomly generated like the example I gave above - ]$wQ^;g2q94@$HRY. If you choose dictionary words, names, places, quotes, words from a book/movie/song/poem/etc. as your passphrase, then 60 characters will result in far less than 60 bytes of entropy.

That's a very good point that I wanted to put in my previous comment but decided to skip it for simplicity.
Technically even a random passphrase like the one you posted is not providing 8-bits of entropy per character because each character doesn't cover the whole 0 to 255 space (although they can if Unicode was used). The upper/lower case English letters + numbers + symbols only has 94 possibilities (instead of 256). So technically 60 is an approximate number and is only accurate if the attacker can not know if the user used the whole 256-bit space or not.

There is also a matter of cost. Even with 60 bytes attacking the BIP39 entropy and going through PBKDF2 and all the other steps has a huge cost that is much higher than just attacking the 64 byte BIP32 seed or the 32 byte private key itself .

[o_e_l_e_o]

Technically even a random passphrase like the one you posted is not providing 8-bits of entropy per character because each character doesn't cover the whole 0 to 255 space (although they can if Unicode was used).

So, out of curiosity, I tested Unicode characters on Electrum and Ian Coleman, both accepted them, and the resulting wallets were reproducible between the two pieces of software, for both Electrum seeds and BIP39 seeds. Are there any hardware wallet which support Unicode characters too? Perhaps Trezor might if you enter the passphrase on the attached device rather than on the hardware wallet itself?

The upper/lower case English letters + numbers + symbols only has 94 possibilities (instead of 256).

95, if you include "space".

[pooya87]

So, out of curiosity, I tested Unicode characters on Electrum and Ian Coleman, both accepted them, and the resulting wallets were reproducible between the two pieces of software, for both Electrum seeds and BIP39 seeds. Are there any hardware wallet which support Unicode characters too? Perhaps Trezor might if you enter the passphrase on the attached device rather than on the hardware wallet itself?

The code should support it since it is a simple matter of normalization and BIP39 reference implementation is from Trezor so it all comes down to the UI that is being used. Both Kivy (for Electrum) and browser (for Ian Coleman tool) are capable of accepting Unicode characters but for example I know AvaloniaUI has trouble with anything that is not UTF8 so a wallet like Wasabi (and by extension when HW is connected to it) shouldn't be able to enter such characters.

95, if you include "space".

I always forget about space