<p><code>PSBT_*_BIP32_DERIVATION</code> can and should be used even for keys that are not BIP32 derived. It would simply be the fingerprint of the key itself, followed by a derivation path of 0 length. Every key can be represented as being derived from itself with the derivation path of <code>m</code>.</p>
<blockquote>
<p>For inputs, assuming p2wpkh for simplicity, I suppose one can use PSBT_IN_HASH160 with the pubkey hash from the output script as keydata and the pubkey as valuedata.</p>
</blockquote>
<p>I would not recommend doing that. Signers will not be expecting keys to be provided in <code>PSBT_IN_HASH160</code>. That field is really for finalizers so that they can build the scriptSig/witness.</p>

CC BY-SA 4.0
2021-10-28T16:45:10.703Z
2021-10-28T16:45:10.703Z
Ava Chow
<p>In a PSBT, version 0 or 2, how would a signer know what keypair to use for an input or an output <em>if the keypair isn't derived through bip32</em>?</p>
<p>For inputs, assuming p2wpkh for simplicity, I suppose one can use PSBT_IN_HASH160 with the pubkey hash from the output script as keydata and the pubkey as valuedata.</p>
<p>But how would you identify the pubkey for an output? There is no way to convey that information via the PSBT, it seems.</p>
<p>(The signer thus needs to maintain a map from pubkey hashes to pubkeys for all its pubkeys to verify that it owns an output. Alternatively, it can calculate the pubkey hash for each pubkey it knows about until it finds a hash that matches the pubkey hash in the output. It also has to do this for every output of the transaction, since there are no hints in the psbt on which outputs are signable by the signer. The pubkeys needs to be hashed at most once, though, because you can check each pubkey hash against all outputs.)</p>

CC BY-SA 4.0
2021-10-28T14:49:04.053Z
I don't know what answer you're after. Yes, if the key isn't derived from something else, there is no way to convey how it was derived...
Pieter Wuille
CC BY-SA 4.0
2021-10-28T15:01:41.583Z
I'm asking how to convey *what key* to verify ownership of the output with, not how it was derived.
Kalle Rosenbaum
CC BY-SA 4.0
2021-10-28T15:05:15.043Z
I see; you're right, indeed you need a map from pubkey hashes to pubkeys. I don't think I ever imagined someone would write signing code that _doesn't_ have such a map. Before PSBT that'd be unthinkable - you need that map anyway, as you need it to identify incoming UTXOs, but from a post-PSBT perspective, I guess that's not necessarily a given. The Signing entity could be distinct from the entity that recognizes incoming UTXOs.
Pieter Wuille
CC BY-SA 4.0
2021-10-28T15:17:20.247Z
Yes. I'm thinking of a signer as just a signer, ie no other responsibilities. The map isn't needed as long as the party feeding the unsigned tx (psbt or not) to the device also supplies necessary info to identify all keys needed. It seems PSBT output map isn't designed for non-bip32 keys.
Kalle Rosenbaum
CC BY-SA 4.0
2021-10-28T15:21:22.523Z
Then again, you need a map from public keys to private keys anyway, so I'm not sure what would be gained by removing the need for it to be pubkeyhash-based.
Pieter Wuille
CC BY-SA 4.0
2021-10-28T15:57:20.747Z
I take your responses as "The answer to the original question is that the signer must keep a pkh->pk map in order to verify that an output (of the transaction to sign) belongs to the signer". Thanks. I just wanted to verify that I had understood psbt correctly.
Kalle Rosenbaum
CC BY-SA 4.0
2021-10-28T15:58:59.683Z
For outputs, the signer doesn't *have* to do anything, but they may want to, in order to verify what is change, and e.g. report the amount transacted to a user for confirmation. And a signer could also reasonably not support anything but BIP32 derived keys from one or a small test of xprvs.
Pieter Wuille
<bip174-psbt>
How would a PSBT signer identify a non-bip32 key?
Kalle Rosenbaum
# How would a PSBT signer identify a non-bip32 key?

(Asked by: username_0 on 2021-10-28)

In a PSBT, version 0 or 2, how would a signer know what keypair to use for an input or an output *if the keypair isn't derived through bip32*?

For inputs, assuming p2wpkh for simplicity, I suppose one can use PSBT\_IN\_HASH160 with the pubkey hash from the output script as keydata and the pubkey as valuedata.

But how would you identify the pubkey for an output? There is no way to convey that information via the PSBT, it seems.

(The signer thus needs to maintain a map from pubkey hashes to pubkeys for all its pubkeys to verify that it owns an output. Alternatively, it can calculate the pubkey hash for each pubkey it knows about until it finds a hash that matches the pubkey hash in the output. It also has to do this for every output of the transaction, since there are no hints in the psbt on which outputs are signable by the signer. The pubkeys needs to be hashed at most once, though, because you can check each pubkey hash against all outputs.)

**Tags:** bip174-psbt

> **Comments:**
> **username_1**: I don't know what answer you're after. Yes, if the key isn't derived from something else, there is no way to convey how it was derived...  
> **username_0**: I'm asking how to convey *what key* to verify ownership of the output with, not how it was derived.  
> **username_1**: I see; you're right, indeed you need a map from pubkey hashes to pubkeys. I don't think I ever imagined someone would write signing code that _doesn't_ have such a map. Before PSBT that'd be unthinkable - you need that map anyway, as you need it to identify incoming UTXOs, but from a post-PSBT perspective, I guess that's not necessarily a given. The Signing entity could be distinct from the entity that recognizes incoming UTXOs.  
> **username_0**: Yes. I'm thinking of a signer as just a signer, ie no other responsibilities. The map isn't needed as long as the party feeding the unsigned tx (psbt or not) to the device also supplies necessary info to identify all keys needed. It seems PSBT output map isn't designed for non-bip32 keys.  
> **username_1**: Then again, you need a map from public keys to private keys anyway, so I'm not sure what would be gained by removing the need for it to be pubkeyhash-based.  
> **username_0**: I take your responses as "The answer to the original question is that the signer must keep a pkh->pk map in order to verify that an output (of the transaction to sign) belongs to the signer". Thanks. I just wanted to verify that I had understood psbt correctly.  
> **username_1**: For outputs, the signer doesn't *have* to do anything, but they may want to, in order to verify what is change, and e.g. report the amount transacted to a user for confirmation. And a signer could also reasonably not support anything but BIP32 derived keys from one or a small test of xprvs.  

---

## 1 answers

### Answer by username_2 on 2021-10-28. Score: 2 | Accepted answer

`PSBT_*_BIP32_DERIVATION` can and should be used even for keys that are not BIP32 derived. It would simply be the fingerprint of the key itself, followed by a derivation path of 0 length. Every key can be represented as being derived from itself with the derivation path of `m`.

> For inputs, assuming p2wpkh for simplicity, I suppose one can use PSBT\_IN\_HASH160 with the pubkey hash from the output script as keydata and the pubkey as valuedata.

I would not recommend doing that. Signers will not be expecting keys to be provided in `PSBT_IN_HASH160`. That field is really for finalizers so that they can build the scriptSig/witness.


---

