hw wallet should not be asked for the xpub at m/. BitBox01 (digitalbitbox) stopped working.

[benma]

Hi

Since bafe8a2#diff-4eaf9a810a587a7d17bc1910a7cf00feR423, a HW wallet is asked for the xpub at "m/". For security reasons, the BitBox01 and BitBox02 (we are preparing a plugin for Electrum) do not support getting the root xpub.

I am unsure about the context of why this was added (#5715 seems related), but is there a way to not require this? In theory, the account-level xpub should be sufficient.

With this commit, the BitBox01 (digitalbitbox) plugin stopped working.

[SomberNight]

Thanks.
I had noticed the bitbox not revealing xpub for "m/" when working on those changes, and already worked around it in one case, but forgot to test new wallet creation.
Should be fixed now.

[benma]

Thanks. What is the purpose of this getting m/?

I saw your patch just gets m/0' instead. The BitBox02 restricts getting the xpub only to a small list of supported accounts (specifically only m/49'/0'/n' and m/84'/0'/n' at the moment). Will one of those also do when developing the BitBox02 plugin?

If I understand the purpose better, then we can check which makes most sense (e.g. using one of the above, or adding an api endpoint to give an device identifier, etc.).

[SomberNight]

What the code is trying to do is get the bip32 root fingerprint, to be able to properly construct PSBTs.
Look at PSBT_IN_BIP32_DERIVATION and PSBT_OUT_BIP32_DERIVATION in the BIP.

To give a concrete example, if you use a Coldcard hw wallet, the device itself gets sent a PSBT, deserialises that, displays confirmation prompt to the user, signs the tx, serialises a new PSBT and sends that back.
As the BitBox has its own custom protocol, and is not just sending a PSBT over the wire, it is arguably redundant to construct the PSBT in this case (but that flow is abstracted away and done in all cases)... I guess we could fill it with some deterministic "garbage", I will think a bit about it.

The BitBox02 restricts getting the xpub only to a small list of supported accounts (specifically only m/49'/0'/n' and m/84'/0'/n' at the moment).

One thing that comes to mind is the custom path Electrum uses for storage encryption:

electrum/electrum/storage.py

Lines 41 to 44 in d3fd87e

	def get_derivation_used_for_hw_device_encryption():
	return ("m"
	"/4541509'" # ascii 'ELE' as decimal ("BIP43 purpose")
	"/1112098098'") # ascii 'BIE2' as decimal

Please whitelist that if possible.

[benma]

Thanks. I am not yet very familiar with PSBT, apoloigies for my uninformed questions. Can't the PSBT root xpub just be the account-level xpub, and the input/output derivation paths be two levels (m/<receive|change>/<address index>)? The BIP does not seem to specify what the root xpub and input derivation paths/depths should be.

Edit:

PSBT_GLOBAL_XPUB

It should be the public key at the highest hardened derivation index so that the unhardened child keys used in the transaction can be derived.

So if the xpub is retrieved with m/, the hardened child keys can't be derived. I guess I need to dig into PSBT in more detail, I am quite confused ;)

[SomberNight]

Yes I agree this part of bip174 is quite unclear. Relevant discussion: #5672 (comment)

[benma]

I think I got the reasoning now. I will think about if we should add a 'get root xfp' api endpoint in the BitBox02.

[benma]

I think it would make more sense to use the account xpub (e.g. m/84'/0'/<n>, etc.) instead of m/1', then co-signers can also verify the change output of the cosigner (see here). I suspect that with m/1' or similar, the change output detection might not be working properly with e.g. ColdCard unless the right derivation and xpub are used.

Outside of Electrum, using the the root xfp makes sense to identify which xpub (if any) is yours, alongside the derivation path from root to derive the key.

Inside Electrum, it should be sufficient to use the account-level xpub and fingerprint in the global xpub field (no keypath, zero depth), at least in the BitBox01. Since the account in Electrum already knows which hardware wallet / keystore it is, what the xpub is and what the derivation path is, identification of the signer in PSBT is solved.

In the BitBox02, I will probably add the root fingerprint; then the BitBox02 could sign PSBT's without Electrum, e.g. air-gapped or with other wallets.

[SomberNight]

I think it would make more sense to use the account xpub (e.g. m/84'/0'/, etc.) instead of m/1', then co-signers can also verify the change output of the cosigner (see here). I suspect that with m/1' or similar, the change output detection might not be working properly with e.g. ColdCard unless the right derivation and xpub are used.

There are multiple ways to do change output detection. One way is described in the BIP here.

As per the discussion I linked in my previous comment, if you put a PSBT_GLOBAL_XPUB key, the path given as a value should be a prefix of the corresponding paths given for the PSBT_IN_BIP32_DERIVATION and PSBT_OUT_BIP32_DERIVATION keys re inputs and outputs.
Note that the PSBT_GLOBAL_XPUB field is optional in general.

i.e. the suggested way of doing things is that you put an account xpub as PSBT_GLOBAL_XPUB, for fingerprint you give the root fp and for path the path from the root to the account xpub ("derivation prefix"). For PSBT_IN_BIP32_DERIVATION and PSBT_OUT_BIP32_DERIVATION keys, for fingerprint you give the root fp, and for path you give the full path to that bip32 node from the root.
This way, pubkeys can be derived from the account xpubs, as the derivation suffix is non-hardened.
Further, cosigners can figure out which pubkey is derived from which account xpub by matching root fingerprints between fp in PSBT_IN_BIP32_DERIVATION and fp in PSBT_GLOBAL_XPUB.

It is important to distinguish between hardware wallets according to whether they have state or not (besides seed). A Trezor for example is stateless, all the information must be contained within the PSBT. The Coldcard can be used both in a stateless and in a stateful way. Specifically, you can setup a multisig wallet on a Coldcard by importing a txt file detailing xpubs and fingerprints and derivations and script types of cosigners, before and independent of any PSBT.

Again, for a stateless hww, all info must be in the PSBT. When signing for multisig inputs and with multisig change outputs, the PSBT_GLOBAL_XPUB fields are needed for change detection. The derivation prefix and the root fingerprint are not needed; as you said they could be left empty. However, note that PSBT_IN_BIP32_DERIVATION and PSBT_OUT_BIP32_DERIVATION fields are in fact needed, as otherwise the hww could not figure out which key to sign with. Note that the hw wallet will require full paths, not just derivation suffixes, to make this inference. Further, as above in the linked discussion, the paths for a PSBT_GLOBAL_XPUB key must be a prefix of the paths given for corresponding PSBT_IN_BIP32_DERIVATION and PSBT_OUT_BIP32_DERIVATION keys. So as you need full paths for the latter, you will need to put the true derivation prefix and root fp for PSBT_GLOBAL_XPUB as well (or not include PSBT_GLOBAL_XPUB).

Outside of Electrum, using the the root xfp makes sense to identify which xpub (if any) is yours, alongside the derivation path from root to derive the key.

Inside Electrum, it should be sufficient to use the account-level xpub and fingerprint in the global xpub field (no keypath, zero depth), at least in the BitBox01. Since the account in Electrum already knows which hardware wallet / keystore it is, what the xpub is and what the derivation path is, identification of the signer in PSBT is solved.

Electrum does not even need the PSBT_GLOBAL_XPUB field at all, as it has state: it already has the xpubs. Furthermore, re PSBT_IN_BIP32_DERIVATION and PSBT_OUT_BIP32_DERIVATION, Electrum handles both just the derivation prefix or the full derivation path (irrespective of what is in the PSBT_GLOBAL_XPUB fields). This goes beyond what the standard specifies, again, as per linked discussion. Rather, the question is how to export PSBTs; as others might not go beyond what the standard specifies.

Currently, Electrum populates PSBT_GLOBAL_XPUB fields just before signing and remove them just after signing (so they are not present in the common export flow). In the case of hw wallets, this would be the scenario when the python process communicates with them via hidapi or libusb. This way, the signer can use them if they want; but if e.g. the user just exports a tx it would not contain an xpub, greatly improving privacy (compared to legacy electrum partial txns).

Re exports themselves, there are currently three types of exports:

So, 3 types of exports (x3 mediums):

• main/common type is "for-signing": include everything we know, except global xpubs and derivation prefixes (so this is reasonably privacy-friendly)
• "for coinjoin": strip all globals, all output info, and bip32 paths re inputs
• "for coldcard": include everything we know, including global xpubs and full derivation paths

---

Further, consider the following example setup:
User has Electrum on online machine. This machine only has account xpub, does not even have derivation prefix.
User has Electrum on offline machine.
User has hw wallet device connected to offline machine.
User prepares PSBT on online machine, transfers it to offline machine. Offline Electrum can now populate global xpub fields; and add derivation prefixes and root fingerprints wherever needed, or other such missing data in general, before communication flow with hw device.
Hw device can now sign. Electrum on offline machine can even remove some privacy critical data if desired.
User can now transfer PSBT to online machine and broadcast there.

The offline Electrum in this scenario functions as an "Updater" in BIP174 terminology (a second updater; as the online Electrum was also an updater in addition to being the "Creator" as well).

Point in the scenario being, if you are cosigning, some design decisions re what to put into PSBT at what point might mean that you require cosigners to run their own Updater on the PSBT before they can sign (as opposed to the Creator's Updater filling in all details). This limits some sdcard usecases.

Sorry for the wall of text, this ended up being quite long :)

[SomberNight]

I'll reclose actually, as the original issue was solved.