Hardware wallet support

Sjors commented at 10:25 am on September 4, 2018: member

Potential benefits of using hardware wallets in combination with Bitcoin Core:

privacy: all or most hardware wallets rely on a backend to fetch balance and history
less vendor-specific code to trust, including much of their dependencies (e.g. hardware wallet software often uses ElectronJS and the whole Javascript kitchen sink)
potentially safer coin storage for Bitcoin Core users than just a wallet.dat file

Current easy to use alternatives:

use the official wallet that goes with the device
use a different wallet (e.g. Electrum)

Current advanced alternatives:

Probably out of scope:

hardware drivers; i.e. there will always be some binary from manufacturer that the user needs to install and trust
UI changes more complex than “Please approve the transaction on your device”

Potential ingredients:

drivers:
- https://github.com/achow101/HWI: combines various hardware drivers into a consistent API. Uses Python, perhaps rewrite in C++? Drivers from e.g. Ledger and Trezor also in Python though.
- https://github.com/signal11/hidapi: multi-platform USB/Bluetooth driver written in C++: could perhaps be added to depends to minimize the amount of vendor-specific code users need to trust?
- perhaps the above is too much detail, and we should just specify a list of function calls that the wallet can make to the driver?
BIP-174 partially signed transactions are now supported
output descriptors
wallet flags (e.g. watch-only)
dynamic wallet loading and creation

Previous issues discussing this:

#10112 (initially about Yubikey, but more broad)
#8218 (initially about Trezor, but also more broad)

I imagine a UX like this:

User installs hardware driver
User starts Bitcoin Core and inserts hardware wallet
Core detects this driver and checks device id against all loaded wallets 3a. If no wallet is found, add menu entry “Create wallet with device X” 3b. Core asks device for account xpub m/49'/0' (or whatever user enters) 3c. Derive keys (driver provides output descriptor for change and receive addresses, e.g. /0/* and /1/*) 3d. Mark wallet as watch-only and store the device id. 3e. Ask driver if this is an existing or fresh wallet, rescan if needed
When user makes a transaction and wallet has a device id, check with driver that device is inserted, then ask device to sign transaction

What seems to be missing is some sort of reverse-RPC, where the Bitcoin Core can take initiative, e.g. asking the device “give me an xpub”, or “sign this”. Perhaps drivers can symlink a standardized RPC at $bitcoin_datadir/hardware/device-id?

achow101 commented at 1:24 pm on September 4, 2018: member

The goal of the HWI project is to facilitate this. The fact that it is written in python is irrelevant. It is a program that can be invoked by Core (e.g. fork and pipe) whenever something involving hardware wallets needs to be done. It abstracts away all of the device specific driver stuff so users (and Core) only need to know some basic commands in order to do anything. HWI can also have its own UI for interacting with hardware wallets for things like pin entry.

The idea that I had was that we would include HWI in the binary distribution (maybe separately?) but in a place that Core would know where to find it. Then when a hardware wallet thing needs to happen, it would just call HWI which would do whatever command and Core would get the result back as a JSON string.

With #14019, #14021, and #14075, you can use a hardware wallet with Core via HWI. The process is very manual, but it certainly is doable and not as bad as one might think.

instagibbs commented at 2:40 pm on September 4, 2018: member

I’ve been dogfooding the PRs @achow101 has mentioned along with HWI. It’s a serviceable replacement for my previous pre-PSBT effort which basically does as he says, calls out to the driver for whatever reason requested: https://github.com/instagibbs/bitcoin/tree/external_sign_10 . (and the PSBT work actually signs anything that Core can sign, unlike my older branch which didn’t do multisig)

My guess is any integrated version of this will have to happen post-descriptors refactor, where the wallet is more sane about what it thinks it has. For now the raw watchonly version is still viable however.

Sjors commented at 3:21 pm on September 4, 2018: member

@instagibbs added a link to your branch to the description for reference (under advanced) @achow101 is there a guide on how to use your approach?

I would prefer creating a fresh wallet rather than importing keys. We could e.g. add descriptor arguments to createwallet. This would require changes to the wallet format so it can handle a root xpub (instead of xpriv) and arbitrary derivation descriptors for receive and change addresses. But it would be easier to understand which keys it has, compared to a scenario where it has some keys by itself and others on a device.

Of course a completely generic solution which also magically handles multisig would be sweet.

sipa commented at 3:59 pm on September 4, 2018: member

@sjors I’m working on adding support for importing descriptors into the wallet (which would automatically support xpubs, multisig, …).

jb55 commented at 4:19 pm on September 4, 2018: member

@achow101 “you can use a hardware wallet with Core via HWI” is a bit vague. Will you be able to import all of your Trezor addresses into core? That’s the main use case I care about and it’s not immediately clear that it’s possible from those commits.

One other commit that comes to mind is #8723

instagibbs commented at 4:24 pm on September 4, 2018: member

@jb55 see “getkeypool” command in HWI. It returns everything necesarry to importmulti the addresses and the pubkey knowledge to generate addresses and create PSBTs Core-side via RPC.

achow101 commented at 7:50 pm on September 4, 2018: member

@Sjors @jb55 I’ve written up a quick guide on how you can use BItcoin Core and HWI: https://gist.github.com/achow101/a9cf757d45df56753fae9d65db4d6e1d

jb55 commented at 8:32 pm on September 4, 2018: member

@achow101 writes:

@Sjors @jb55 I’ve written up a quick guide on how you can use BItcoin Core and HWI: https://gist.github.com/achow101/a9cf757d45df56753fae9d65db4d6e1d

This is great, thanks! My intuition is that this looks to be the right way to go about it, as all the complexity/new hw wallet support can be handled by HWI. Looking at your docs, I imagine it wouldn’t be too difficult to put a friendly GUI around it as well.

kewde commented at 9:02 pm on September 4, 2018: contributor

I’ll just drop this here. I suppose it can be a relevant resource to someone that wishes to do an implementation in bitcoin-core using hidapi. https://github.com/particl/particl-core/tree/master/src/usbdevice

fanquake added the label Feature on Sep 6, 2018

fanquake added the label Brainstorming on Sep 6, 2018

Sjors commented at 8:04 pm on September 13, 2018: member

I just successfully tried @achow101’s instructions. TL&DR:

Python script gets a bunch of addresses from the device, e.g. m/44'/0'/0'/0/[0-99]
add keys to keypool using RPC; the above output is easy to copy-paste. Needs #14075 to make keypool work with watch-only wallet.
to receive coins, no hardware wallet needed, just generate addresses (legacy, p2sh, bech32) as usual
to send coins, generate a PSBT and pass that into the python script (needs #14021 to keep track of BIP32 paths), device signs it, and script returns PSBT, which you then parse and broadcast with RPC

Review of #14019, #14021, and #14075 would be quite helpful to move this forward. In addition, @ken2812221’s #13966 makes these watch-only wallets more pleasant to look at in QT.

Sjors commented at 2:47 pm on December 10, 2018: member

More progress: #14912

Sjors commented at 2:22 pm on February 19, 2019: member

I gave a presentation at Advancing Bitcoin about the latest state of this. Video and slides.

The Python hardware wallet drivers @achow101 created have been moved to the Bitcoin Core Github account and should work with v0.18 once that’s released. Usage is described here.

I’m adding a number of RPC methods to bitcoind to make it easier to use the HWI library, which is work in progress in #14912 that I linked to earlier.

Work on the GUI can probably get started once create wallet functionality is added, the only thing missing from #13059. In fact, the verify address on device and sending transaction functionality can already be worked on even while wallets needs to be created with the command line.

Sjors commented at 9:01 am on October 29, 2019: member

Two main blockers for this are:

#16966 ui: make send a wizard; this creates space in the send UI to sign on devices (or handle PSBTs directly). I plan to rebase #16549 UI external signer support (e.g. hardware wallet) on top of that when it’s a bit more stable.
#16528 native descriptor wallets: although not strictly necessary, descriptor wallets make it easier to stay interoperable with manufacturer wallets that use BIP44/49/84, and makes it easier to support multisig (e.g. BIP67, #16895)

Sjors commented at 11:50 am on June 25, 2021: member

We have liftoff!

Sjors closed this on Jun 25, 2021

DrahtBot locked this on Aug 18, 2022

Hardware wallet support #14145