We derived the xprv at keypath twice to mitigate potential bit-flips. Such a bit-flip could be devestating if it happened during computation of an xpub or address returned to the host computer, as funds sent to it could not be recovered.
We plan to encrypt the seed in RAM, involving the securechip, whose use is costly (~100ms per KDF invocation). Since the xprv is needed each input to sign an input in a Bitcoin transaction, computing the xprv twice doubles the time needed to sign an input. There, computing it twice is not needed, as a potential bit flip (which is very unlikely in the first place) would simply result in invalid signatures and a rejected transaction.
The keystore_get_xpub function is still called when accumulating the inputs hash of a BTC transaction (in the first round of inputs streaming in signtx.rs, using common::Payload::from), which is still computed twice. Here, only one round is sufficient as well, but the performance impact here is small, as the xpubs are cached using Bip32XpubCache. Maybe we will still improve this in another commit.
We derived the xprv at keypath twice to mitigate potential bit-flips. Such a bit-flip could be devestating if it happened during computation of an xpub or address returned to the host computer, as funds sent to it could not be recovered.
We plan to encrypt the seed in RAM, involving the securechip, whose use is costly (~100ms per KDF invocation). Since the xprv is needed each input to sign an input in a Bitcoin transaction, computing the xprv twice doubles the time needed to sign an input. There, computing it twice is not needed, as a potential bit flip (which is very unlikely in the first place) would simply result in invalid signatures and a rejected transaction.
The keystore_get_xpub function is still called when accumulating the inputs hash of a BTC transaction (in the first round of inputs streaming in signtx.rs, using
common::Payload::from), which is still computed twice. Here, only one round is sufficient as well, but the performance impact here is small, as the xpubs are cached usingBip32XpubCache. Maybe we will still improve this in another commit.