cc @stepansnigirev @peter-conalgo

+1 would implement

Just to clarify

It should be the public key at the highest hardened derivation index

Should means that it's a recommendation and I still can use non-hardened derivation index, right? If so, +1 from my side.

Should means that it's a recommendation and I still can use non-hardened derivation index, right?

Yes. It is a recommendation, not a requirement.

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.

This is a somewhat confusing sentence. At a minimum, the word highest seems ambiguous. Perhaps an example could also be provided to clarify?

I think we're going to need a different 'key' for this field. Here are three xpub's with the same fingerprint, and if BIP45 was being used, they would all have the same derivation (m/45'). Without having a repeating key value, there is no way to represent this in the proposed PSBT format.

tpubD8NXmKsmWp3a3HvTG3Pe2mmkmwMfNPvVd4GorFdaQpnwV8v79zEchTuLkt1Ehz7ou5icAFYxDbS7gR592VocShPqNnmwDQcdbcPdDyVhAiG
tpubD8NXmKsmWp3a2S1WnJk9GBXBpJNEWEd5HEQsMtV29Kk4uBzxuH1JGBq8oLAHmmVgZCiXdGANT35niN1ibSZatwQ7zHYsTtWrzjo6aKK11g4
tpubD8NXmKsmWp3a1Hj6i1Be5fVbbRfH4Hg2reAZ9ctaizJFc9ddLG5GSHnS4f3iprEmrbFPWLmgsir2s9CaXQp2fVVMs5zVbJTnhvMxoErXQCW

[Aside: All share F1CFD170. These are constructed by modulating the chain code, but as a 32-bit truncated hash, there will be legitimate fingerprint collisions in real-world examples.]

As for a better key value to use, I think an index (32-bits, ascending) would be enough, or we could use the public key (33 bytes, compressed only).

IMHO, the key derivation path is not useful information since I cannot verify it, but maybe it's useful to detect innocent errors between the global section and paths in the ins/outs.

In conclusion, I propose we switch from using the (extended key fingerprint + key path) to just an (index + key path). Must start at zero, no gaps and so on.

In conclusion, I propose we switch from using the (extended key fingerprint + key path) to just an (index + key path). Must start at zero, no gaps and so on.

I don't think requiring it to start at 0 and increment is really needed. We just need some fixed sized nonce that makes it unique. Also, I think it would be worth keeping the extended key fingerprint as that would allow for efficient lookups in the case where fingerprints don't collide. So the key would be nonce + fingerprint + path. I would prefer something else that can be used for uniqueness that would be known from the child pubkey, although I can't think of one right now.

• yes to keeping the fingerprint, I missed that, and we need it for any xpub that has child_depth > 1.
• nonce vs. index: sure. I'd use an index myself and still be compliant.

We could use the fingerprint of the key itself as a nonce. It's a bit redundant as it can be calculated from the xpub, but sometimes people don't know the root fingerprint and use the fingerprint of the last hardened key instead. So it may help to do quick lookups in such cases.
Or we could save 3 bytes and use a 1-byte nonce without any meaning - should be enough to prevent collisions.

I don't understand the reasoning. Because A wallet should already know out of band the xpub of B if his wallet want to create a new deposit address.

If A knows about the xpubs out of band, then he can detect that the output of E is not the proper change.

It is not specific to multisig wallets actually. In general the wallet A should know how to derive addresses, and as such know the xpubs already. Not only the xpub, but if you make a more complex wallet based on mini script for example, the wallet A not only need all the xpub out of band, but also the miniscript!

Also, what if the attacker replace the xpubof B in PSBT_GLOBAL_XPUB with his?

I can only comment on the Coldcard. We will support out-of-band methods to setup the xpubs involved in a multisig wallet, and also support the PSBT globals section. However there is a setting, called "Trust PSBT" with values:

• Verify Only. Do not import the xpubs found, but do verify the correct wallet already exists on the Coldcard.

• Offer Import. If it's a new multisig wallet, offer to import the details and store them as a new wallet in the Coldcard. (The user can view fingerprints and xpubs and M/N at this point before import.)

• Trust PSBT. Use the wallet data in the PSBT as a temporary, multisig wallet, and do not import it. This permits some deniability and additional privacy.

When the XPUB data is not provided in the PSBT, regardless of the above, we require the appropriate multisig wallet to already exist on the Coldcard. Default is to 'Offer' unless a multisig wallet already exists, otherwise 'Verify'.

@peter-conalgo

and also support the PSBT globals section.

Stop me if I miss something, but if Coldcard does not know the xpubs out of band, then what prevent the attacker to put his own xpub in the PSBT global section? I don't understand how this proposal fix the problem it is aiming to solve.

In my opinion, hardware wallets must track the M/N and xpubs for multisig wallets with which they are involved or else, yes, they will be vulnerable to changes to the PSBT. How that is stored/setup is out of scope for BIP-174 (IMHO) but with this addition to the PSBT format, HW wallets can implement a "trust on first use" model, which has proven to be very useful security model (example: SSH server pub keys).

@peter-conalgo good point. I think that @achow101 should clearly clarify this.

The "trust on first use" is the only reason for this global xpub field.
This seems a good way to initialize a multisig wallet.

@peter-conalgo I think that this global xpub is not even useful in trust on first use scenario. Because you can't even know about m...

@NicolasDorier Coldcard takes M/N from the first multisig input of the associated transaction.

@NicolasDorier, why is it the only reason?
When multisignature wallet already exists and I am doing a transaction with some change going back to the wallet how can I verify that the change address uses the same master public keys without xpubs? That was the idea of this change. Storing xpubs on hardware wallets is an option, but if the hardware wallet is stateless (or wiped and initialized again) it helps.

@stepansnigirev because the attacker E can put his own xpub in this global field, and the HW has no way to know.

I like @peter-conalgo approach as this technique can be used as a very good UX to initialize wallets with more complex scripts without changing or adding PSBT fields later.

So there is an xpub E from the attacker, it is not in the input but it is in the output => the address is not a change address and we need to show to the user that keys are different.
Let's say input is from 2 of 3 multisig with keys xpub1/derivation1, xpub2/derivation2, xpub3/derivation3, if the output uses the same xpubs it will be considered as change address, if not - spending output. How can the attacker include his E in the output?

Can you describe the attack you are thinking of in more details? I don't understand.

@stepansnigirev

• Global XPubs: A,B,E
• Input 1: A+B (1/2)
• Output 1: Destination
• Output 2: A+E (1/2)

A see that A and B are in input 1 => OK
Then A see that A and E are in output 2 => OK that's change

@stepansnigirev I don't believe about a stateless wallet which can't save in its memory the multi sig xpubs and m. Because how the HW would be able to give you securely a new address? How could you confirm securely on the trusted display that an address you see on your computer screen is indeed belonging to your secure wallet?

I am not against this BIP, but I think it is created for the wrong reason. And if HW wallet use this feature the wrong way here the problems:

• Software supporting PSBT but not supporting the global XPUB will be unable to be used with HW wallet depending on this, resulting in user confusion. (@peter-conalgo use case of trust on first use does not fall into this problem, as coldcard will not require this field)
• There is still many way to trick the HW into thinking an output is a change. This is a mine field, and the easiest way to deal with this minefield is by making sure the HW can itself derive the scriptPubKey, without relying on the PSBT (outside of the keypaths in the output).

@NicolasDorier , change address is a change address if ALL keys in inputs and change output are the same. As (A,B) != (A,E) the second output is not a change address => HW will show it as spending output.

Software that doesn't use xpubs will be able to use hardware wallets with single keys (without multisig) or with multisig but the change address will be shown to the user as a normal spending address if the hardware wallet doesn't store the xpubs. It HW stores xpubs - no problem, HW can ignore this field.

At the moment the fact that we are missing xpubs field in the standard makes PSBT incompatible with Trezor wallet. They don't use PSBT but they rely on xpubs.

@stepansnigirev so in this case it means:

1. Wallet requiring this can't sign a coinjoined transaction. (because if there is two input A+B and A+E, then you need to use an heuristic to say "this should be a transaction signed by the A+B wallet because input A+B is the first input")
2. They need additional logic to extract the template of the scriptPubKey of A+B and enforce that the change has the same template. Which is not an obvious thing to do outside the simplest case of multisig. (Even for multisig, this is hard as you don't know if you need to reorder the pubkeys lexicographically or not)

@stepansnigirev if the HW does not understand PSBT natively like coldcard does, then the responsibility to tell what is the change or not goes to the component interfacing with the HW (like HWI). This component should pass some hints to the HW to tell which input and output to sign explicitly, which can be done outside of the PSBT spec. (this make sense because which input and output to sign for a wallet is not known by the PSBT creator)

Datapoint: Coldcard will reject any redeem script that doesn't have sorted public keys (per BIP-67), inputs or outputs.

Aside: We are putting the finishing touches on Coldcard's multisig support (see branch 'multisig'), and we already support the global XPUB field as originally proposed (with 32bit-nonce addition). Also, psbt_dump will parse and display them.

@achow101 Could you add the nonce from upthread into the diff which we are discussing?

My comment as a hardware wallet maker: to be safe the Coldcard has to understand precisely what we are signing. Therefore, duplicating any value that can be derived from the transaction itself is not helpful. It just becomes another value that we have to double-check. I like the original proposal as it provides just the information we need and no more. The proposal is sufficient for multisig, and IMHO, other transaction types, like Coinjoin, can add additional metadata to appropriate PSBT sections when we understand what they need to be safely signed.

Ok then if you insist on making this global xpub field, at list, in the BIP, describe how a HW should behave precisely, if I understand:

1. Check first input's script, and extract m.
2. Verify that the pubkeys in the input's script are all derived from xpubs present in the global xpub field.
3. Verify that the pubkeys are ordered per BIP-67
4. For each output, if the output's scriptPubKey can be derived from the xpubs extracted in the first input, m and the key paths, consider it as a change.

describe how a HW should behave precisely,

I think that is completely out of scope for this BIP. It is not a specification of how hardware wallets should behave, it is a description of a data structure and the abstract workflow around it.

@peter-conalgo I don't really like the nonce idea. Do you really think that collisions will really be a problem? The probability of having a master key fingerprint colliding within a PSBT is very low and in many other places, the master fingerprint is being used for uniqueness.

Collisions with a 32-bit truncated-hash can be legit---it's only mildly bad luck by my standards. I don't see any other spots in BIP-174 where BIP32 path is the key, so I think this is the only area with this potential problem. Of course the various implementations will still fall over, but that's not a concern when defining the file format. We just have to make it possible to create a conforming implementation that handles all cases.

Alternatives to the 32-bit nonce idea:

1. We could loosen the rules about duplicate key values, maybe only in the global section, to allow repeated keys (but not repeated (key, value) pairs).

2. We could insert a reserved value into the keypath when needed to make it unique (perhaps all ones). In case of multiple duplicates, you'd insert two of the reserved values.

3. Use something else as the key, even just a counter, and then append the bip32 path after the xpub. More complex perhaps, but does allow growth in the future.

The problem I see with (1) and (2) is they won't get implemented, since they only happen in this special case. Most coders are happy with "works most of the time"... The nonce idea, and (3) force implementations to do it right.

I prefer a solution forcing implementation to do it right. Else we will end up with people having money locked unexpectedly (unless they are wizards).

What if we flip key and value? Having xpub as a key and derivation path as a value would prevent collisions. It's harder to do lookups though.
The only concern I have is that you could have multiple derivation paths for the same xpub depending on which parent key you consider a master key.

I've updated the changes as was discussed at Breaking Bitcoin.

The key is changed to be the xpub and the value is the derivation path. The depth of the provided derivation path must match the depth specified in the xpub.

I've also added a section on how change detection would work with this.

Looks good to me.

@luke-jr This looks to be RTM.

@luke-jr This can be merged.

@achow101 do you have a test vector somewhere?

Here is what I get:

cHNidP8BAJoCAAAAAqmeyBQKKaI4mLDsQKtdpzGKG+W1MpcqHafaxBqbiHg8AAAAAAD/////qZ7IFAopojiYsOxAq12nMYob5bUylyodp9rEGpuIeDwBAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAATwEENYfPA9tUzYaAAAAAPyQBTmKLwpLRdTq/jl153VaJxd4KnlaDe6Lv6N2k8KEClYO/Oa4KYJdHrRma3dY0+mEIVZ1sXNObTCGD8auW4H8Q2QxqTwAAAIAAAACAAAAAgAABAE4BAAAIAAIAwusLAAAAABl2qRQFw/p8wLK+KgyugzKd8/kd2nKDjoisAMLrCwAAAAAZdqkUHatMqMPhz5T3nB9d5BX6mSv77jGIrAAAAAAiBgPM2yteF/6Eznlt1wjiHtdnWCue+MH/36jP8/gx7RMm2xTZDGpPAAAAgAAAAIAAAACAAAAAgAABAE4BAAAIAAIAwusLAAAAABl2qRQFw/p8wLK+KgyugzKd8/kd2nKDjoisAMLrCwAAAAAZdqkUHatMqMPhz5T3nB9d5BX6mSv77jGIrAAAAAAiBgJ8eKXzQrU9QnNbxV5xU2g6eyIl9Pug2hG25WklswpitRTZDGpPAAAAgAAAAIAAAACAAQAAgAAAAA==

So, after properly reading this entire thread, I've come to realize that Cold-card is trying to implement a feature similar to my other global data point proposal #801

However, instead of internalizing the whitelist data (via an HW internal state combined with Trust on First Seen) my proposal is to create a signature with a specific private key of the HW seed, and have that signature passed in through the PSBT... meaning the wallet does not need an internal state.

My proposal also seems to deal with a few of @NicolasDorier concerns... (though some are still existing)