Why was the bip32 fingerprint used for bip174 psbt?

Question

The fingerprint is widely used across the bip174 psbt specification. This is done to speedup parsing for a signer such that he

can observe whether the master fingerprint for the public key for that output belongs to itself (as quoted from BIP174).

BIP32 defined the fingerprint as the first 4 bytes of the hash160 of a public key. It also says that

Note that the fingerprint of the parent only serves as a fast way to detect parent and child nodes in software, and software must be willing to deal with collisions. Internally, the full 160-bit identifier could be used.

Why was the fingerprint chosen for psbt instead of the full hash? Collisions aren't that rare for just 4 bytes of data and adding mitigations in the psbt transaction parsing for such a case seems unnecessarily complicated.

There is also the issue that if the chain code changes without the public keys changing, the fingerprint will remain the same. If this would be the case, the fingerprint would be identical between two identical public keys, but each would lead to differently derived child keys. This leaves even more work for collision detection and potentially even destroys the benefits of using the fingerprint for fast account ownership checks.

Answer 1

Why was the fingerprint chosen for psbt instead of the full hash? Collisions aren't that rare for just 4 bytes of data and adding mitigations in the psbt transaction parsing for such a case seems unnecessarily complicated.

Fingerprint collisions would still require thousands of signers in a single PSBT to actually be a problem. Collisions aren't all that probable when you consider the circumstances.

There is also a practical issue. You can't get the full pubkey hash160 from hardware wallets. There is no existing standard that includes this data and no existing APIs that export it. In some devices, you could get the master public key and hash it yourself, but not all devices supported getting that. The fingerprint is far easier to get, just get the xpub for the key at m/0h and pull the parent fingerprint from that.

There is also the issue that if the chain code changes without the public keys changing, the fingerprint will remain the same. If this would be the case, the fingerprint would be identical between two identical public keys, but each would lead to differently derived child keys. This leaves even more work for collision detection and potentially even destroys the benefits of using the fingerprint for fast account ownership checks.

I don't see how this would even be possible unless you are intentionally messing around with the chaincode, and I don't see why you would be.

The chaincode is derived by hashing the BIP 32 seed with HMAC-SHA512 and taking the last 256 bits. The first 256 bits becomes the master private key. So you would have to somehow collide the first 256 bits (and thus have the private component of the master private key). But that is highly improbable and is akin to a normal private key collision. The only situation where you could possible have the same public keys but different chaincodes is if you were directly modifying the chaincode itself, but I see no reason for anyone to do this, and if they were, they would really only be inconveniencing themselves.