BIP38 (Part 2)
Last updated
Last updated
We already looked at using BIP38 to encrypt a key, however this BIP is in reality two ideas in one document.
The second part of the BIP, shows how you can delegate Key and Address creation to an untrusted peer. It will fix one of our concerns.
The idea is to generate a PassphraseCode to the key generator. With this PassphraseCode, they will be able to generate encrypted keys on your behalf, without knowing your password, nor any private key.
This PassphraseCode can be given to your key generator in WIF format.
Tip: In NBitcoin, all types prefixed by “Bitcoin” are Base58 (WIF) data.
So, as a user that wants to delegate key creation, first you will create the PassphraseCode.
You then give this passphraseCode to a third party key generator.
The third party will then generate new encrypted keys for you.
This EncryptedKeyResult has lots of information:
First: the generated bitcoin address,
then the EncryptedKey itself (as we have seen in the previous, Key Encryption lesson),
and, last but not least, the ConfirmationCode, so that the third party can prove that the generated key and address correspond to your password.
As the owner, once you receive this information, you need to check that the key generator did not cheat by using ConfirmationCode.Check(), then get your private key with your password:
So, we have just seen how the third party can generate encrypted keys on your behalf, without knowing your password and private key.
However, one problem remains:
All backups of your wallet that you have will become outdated when you generate a new key.
BIP 32, or Hierarchical Deterministic Wallets (HD wallets) proposes another solution, which is more widely supported.