2

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.

4

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.

| improve this answer | |
  • > Fingerprint collisions would still require thousands of signers in a single PSBT to actually be a problem. Why would the collisions only be limited to a single PSBT? Seems to me that a collision every 60000 or so transactions (if I am calculating this correctly) is still quite high and definitely needs resolving code implemented. I am also sure that hardware wallets could adopt an endpoint that would expose the full hash160. – TheCharlatan Jan 16 at 22:40
  • 1
    Why would it matter that a fingerprint in a PSBT collides with a fingerprint in another independent PSBT? The issue with collisions is that within a single PSBT, it would be ambiguous as to who the actual signer is. But if you have two PSBTs that happen to have different signers with the same fingerprint, what is the issue there? – Andrew Chow Jan 17 at 13:13
  • You are right, my math is wrong, thank you for your answer Andrew. – TheCharlatan Jan 17 at 14:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.