user69518: 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.)

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

69518: <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>
 48884: <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>
