Deriving Bitcoin transient keys using BIP32

[Franck Royer]

After tackling this clean-up [1] and removing the indirection of the `Network` using `bitcoin::Wallet`'s seed, I thought the logical next step would be to limit the presence of the root seed in memory by only limiting it's usage at initialisation.

One of the barriers to do so is how we derive Bitcoin transient keys [2].

We currently:

- take the seed

- append the swap id's bytes

- append the ascii bytes of "TRANSIENT_KEY"

- Apply sha256

We use the resulting byte array as a secret key.

What we like about this method is that:

- It is one direction: if the secret key is leaked, the seed is not

- It is deterministic per swap: with the seed and the swap id, it is possible to regenerate the private key

 

Now, to solve the issue of keeping the root seed, from which we also generate the Bitcoin and Ethereum wallets, in memory, we could simply generate a new "seed for transient keys" as I did with the network seed in [1].

However, I was wondering if it could make sense to instead use BIP32 derivation to generate transient keys. This would have the advantage of being a more standard way of doing things.

We could use a dedicated derivation path: "m/0'/2'/k'` with `k'` the key index.

We could simply generate the keys in order (or even pre-generate them in a pool like bitcoind).

~While we lose the tight Swap Id <> secret key relation, it could actually allow us to scan the blockchain for our HTLCs~ Actually not, as we also need the counterparty's Bitcoin pubkeys to generate the HTLCs.

The swap id <> secret key relation may not even be necessary. We currently save the transient secret key in the database hence such relation is useless in case of restart.

To justify this relation, we would need to look in more detail at what kind of scenario we want to recover from.

Currently, if a user loses everything but their root seed then some recovery would be possible but quite difficult. I would even challenge that in this case, the swap ids also being lost, the fact that we derive transient keys from them would be an issue. Whereas using BIP32 derivation would allow  recovery in this scenario.

Let me know your thoughts.

[1] https://github.com/coblox/nectar/pull/114

[2] https://github.com/coblox/nectar/blob/a8095f2d03cf2d6a60f1cc2d605290802089d2b0/src/bitcoin/wallet.rs#L83