<blockquote>
  <p>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. </p>
</blockquote>

<p>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.</p>

<p>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 <code>m/0h</code> and pull the parent fingerprint from that.</p>

<blockquote>
  <p>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.</p>
</blockquote>

<p>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.</p>

<p>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.</p>

CC BY-SA 4.0
2020-01-16T22:40:01.313Z
> 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
CC BY-SA 4.0
2020-01-17T13:13:17.077Z
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?
Ava Chow
CC BY-SA 4.0
2020-01-17T14:25:02.330Z
You are right, my math is wrong, thank you for your answer Andrew.
TheCharlatan
CC BY-SA 4.0
2020-01-16T17:10:12.443Z
2020-01-16T17:10:12.443Z
Ava Chow
<p>The fingerprint is widely used across the bip174 psbt specification. This is done to speedup parsing for a signer such that he</p>

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

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

<blockquote>
  <p>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.</p>
</blockquote>

<p>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. </p>

<p>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.</p>

<bip32-hd-wallets><bip174-psbt>
Why was the bip32 fingerprint used for bip174 psbt?
TheCharlatan
# Why was the bip32 fingerprint used for bip174 psbt?

(Asked by: username_0 on 2020-01-16)

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.

**Tags:** bip32-hd-wallets, bip174-psbt


---

## 1 answers

### Answer by username_1 on 2020-01-16. Score: 4 | Accepted answer

> 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.

> **Comments:**
> **username_0**: > 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.  
> **username_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?  
> **username_0**: You are right, my math is wrong, thank you for your answer Andrew.  

---

