1

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

7
  • 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... Oct 28 '21 at 14:49
  • I'm asking how to convey what key to verify ownership of the output with, not how it was derived. Oct 28 '21 at 15:01
  • 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. Oct 28 '21 at 15:05
  • 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. Oct 28 '21 at 15:17
  • 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. Oct 28 '21 at 15:21
2

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.

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.