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:

• Electrum Personal Server
• WIP by @instagibbs: master...instagibbs:external_sign_10
• Import pubkeys when importing p2sh with importmulti #14019, Import key origin data through descriptors in importmulti #14021, and Import watch only pubkeys to the keypool if private keys are disabled #14075 by @achow101, guide: https://gist.github.com/achow101/a9cf757d45df56753fae9d65db4d6e1d

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:

• Support for Yubikey #10112 (initially about Yubikey, but more broad)
• Are you going to add Trezor support? #8218 (initially about Trezor, but also more broad)

I imagine a UX like this:

1. User installs hardware driver
2. User starts Bitcoin Core and inserts hardware wallet
3. 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
4. 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?