On hardware wallet signing
In the last day or so I changed how we do Trezor signing so that we provide the signing process with the transactions containing spent coins, and so that their latest firmware can work with ElectrumSV. I feel like I should write some notes about it and make sure I understand where things are with ElectrumSV and hardware wallet signing.
The Trezor team does not provide Bitcoin SV support in their software. You have to use Trezor devices as if you were using Bitcoin Cash.
When ElectrumSV goes to sign a transaction, it detects it needs to provide the transactions that contain the inputs/coins being spent. These are gathered up, and passed with the incomplete transaction to the given account for signing, this passes down to the keystore and from there to the Trezor library and from there to the device.
Unpacking segwit and BIP143
Trezor's article on the subject talks about how providing these input transactions is already required for non-segwit transactions. It also refers to BIP143 and how while this does include the value of the spent coin in the signature, it is not enough. So they require that the transactions containing the spend are also provided for segwit transactions. But remember, when Bitcoin Cash split from Bitcoin Core it changes how transactions were signed to use BIP143 and split before segwit was added. Bitcoin Core non-segwit transactions do not use BIP143.
The exploit being fixed by their changes gets the user to sign differently constructed transactions including combinations of legitimate and illegitimate spends, and then pieces together the legitimate spends to construct another different legitimate transaction.
We already see fake versions of wallets like Electrum Core, Electron Cash and ElectrumSV. That hardware wallets can give some protection against these, is a good thing. Users tend to just click through things in my opinion, so I can see this being exploited. However there is no personal gain in it for the the people who create fake versions of wallets, they can't necessarily pay themselves any money and any funds redirected in this way goes to transaction fees.
This also has overlap with offline signing, so I have no complaints about having ElectrumSV jump through this hoop.
The Keepkey wallet is now owned by Shapeshift, and it is as far as I know a fork of Trezor. After I was finished getting Trezor to work, I took a look at it to see if it needed similar changes.
If you look at the Keepkey support in Electrum Core it does the following:
- Stores the previous transactions for later callbacks to pick up on demand.
- Has a callback that retrieves a stored transaction when the Keepkey library invokes it.
- The Keepkey library does not call it anyway for BIP143-based coins.
Now, Electrum Core is of course for Bitcoin Core, and it's transactions are not signed with BIP143 except presumably the segwit stuff. But this resembles what Trezor said about how BIP143 was not enough, so they require the input transactions for BIP143-related. But clearly Keepkey do not protect against the same exploit that has been fixed in Trezor (and presumably other hardware wallets).
I do wonder if Keepkey, or at least the Python support for it, is still maintained. Their latest release on Github is v6.0.3. Their latest release of the Python package is v6.3.1. I have no idea what v6.3.1 contains, although Electrum Core appears to use it which implies they trust it. If I unpack the source code in the v6.3.1 release, it does not change how it works with respect to BIP143 and transactions containing spent inputs.
I could submit a fix for their Python library to require the previous transactions along with the incomplete one that was being signed, but unless it is required in their firmware so that the firmware actually requests and uses this provided data it is pointless to do so. But is it worth it?
At this time I only have a working Ledger Blue, which appears to no longer be actively supported. This means I do not have a working actively supported Ledger wallet to test against. I have put in an order for a Ledger Nano X, and once it arrives will see where it stands with regard to this.