2

Please comment on the accuracy of this explanation.

Scenario: The master public key is compromised and so all non-hardened public addresses can be generated and monitored by a third party. This negates the privacy gained from avoiding address reuse. (The third party cannot spend any bitcoins from these addresses however).

Hardened public keys cannot be generated from the master public key, and a priori cannot be attributed to the owner of the non-hardened addresses above.

Is it possible to generate such hardened keys in Electrum, and if so, how?

3 Answers 3

1

Electrum uses a few different derivation paths for various script types. For example for legacy p2pkh addresses (addresses beginning with 1) it uses m/n/i where m is the extended private key (xprv) derived from the seed, n is 0 for external and 1 for change addresses and i is the address index with addresses being generated sequentially starting from 0. Electrum also lets you create a wallet using any xprv and then it'll assume that xprv is m in the derivation path and generate addresses relative to that. So all you have to do is restore your wallet from a hardened xprv such m/1' and electrum will then generate addresses relative to that. These addresses will not be visible to the person who has the extended public key for m.

To generate a wallet using m/1' you can use this script like so:

electrum getmasterprivate| python3 xprv.py -m - -d "m/1'" -p|electrum -w wallet_name restore -

0

Is it possible to generate such hardened keys in Electrum, and if so, how?

It is not possible to generate hardened keys in Electrum because Electrum does not allow you to enter your own BIP 32 derivation paths. The hardening is based upon the derivation paths.

0

I didn't actually understand what you want.

Hardened public keys cannot be generated from the master public key, and a priori cannot be attributed to the owner of the non-hardened addresses above.

There's no "hardened xpub (extended public key)" at all.

There are only "hardened childs" or "normal (non-hardened) childs", of one parent xprv (extended private key).

The normal childs are derived from the parent public key, while the hardened childs are derived from the parent private key, so that any hardened childs can only be derived with the knowledge of the parent xprv (which contains the parent private key and the parent chain code).

Currently, Bitcoin Core uses the hardened childs directly as keys of receiving/change addresses (receiving addresses would be m/0'/0'/0', m/0'/0'/1', m/0'/0'/2', ...etc).

As far as I know, Electrum currently doesn't support such "hardened address" option. However, this could be also achieved with other tools, like Ian Coleman's BIP39 tool.


Although @Abudussamad had already provided a straightforward method, I think his method is not standard-compliant, though.

If you just followed his guide, your receiving addresses would be derived through "weird" derivation paths, like m/1'/0/0, m/1'/0/1 ,m/1'/0/2, m/1'/0/3, ...etc, while your change addresses would be derived through m/1'/1/0, m/1'/1/1, m/1'/1/2, m/1'/1/3, ...etc.

See, your addresses will be actually derived at the depth of 3, while regular Electrum wallets derive their addresses at the depth of 2:

The receiving addresses would be m/0/0, m/0/1, m/0/2, ...etc, while the change addresses would be m/1/0, m/1/0, m/1/0, ...etc.


In my opinion, it's better to achieve this goal with the BIP39/44/49/84 standard scheme.

BIP44/49/84 provide separation among different "accounts". If the xpub of "account 0" has already been compromised, you can simply switch to "account 1", which does not have any observable linkage to the compromised "account 0", as long as the parent "coin" xprv (which derives all the "accounts" from 0 to 2^31) is still kept secret.

This is easy to do with a BIP39 mnemonic, although Electrum always shows warnings about it. After checking "Use BIP39 seed" in the option dialog, Electrum will show you three different address type options.

For example, if you chose the legacy address type, Electrum would automatically fill the derivation path with m/44'/0'/0'. The last 0' was the account index number, of the 1st account. You could change this number to other value, like m/44'/0'/1' or m/44'/0'/2', which corresponded to the 2nd or 3rd account respectively.

If you then chose to use the 3rd account (m/44'/0'/2'), your receiving addresses would be m/44'/0'/2'/0/0, m/44'/0'/2'/0/1, m/44'/0'/2'/0/2, m/44'/0'/2'/0/3, ...etc, while your change addresses would be m/44'/0'/2'/1/0, m/44'/0'/2'/1/1, m/44'/0'/2'/1/2, m/44'/0'/2'/1/3, ...etc.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.