> * Key-value map model or set model. > * Ability for Combiners to verify two PSBT are for the same transaction > * Optional signing > * Derivation from xpub or fingerprint > * Generic key offset derivation > * Hex encoding?
I think all of Pieters points are valid and reasonable thought, though I’m
unsure if it would be worth changing the existing-implementation-breaking
things like the k/v set model.
AFAIK things like non-hex-encoding or generic key offset derivation are
extensions and would not break existing implementations.
Further thoughts on BIP174 from my side.
Key derivation in multisig:
From my understanding, the signers and the creator must have agreed – in
advance to the PSBT use case – on a key derivation scheme.
BIP32 derivation is assumed, but may not always be the case.
Sharing xpubs (the chaincode) may be a concern in non-trust-relationships
between signer(s) and the creator (regarding Pieters xpub/fingerprint concerns).
Providing the type 0x03, the bip32 derivation path is one form of a support to
faster (or computational possible) derivation of the required keys for signing
a particular input.
From my point of view, it is a support of additional metadata shared between
creator and signer and provided from the creator to the signer for faster (or
computation possible) key deviation.
I think it could be more flexible (generic) in BIP174.
It could be just a single child key {32-bit int}, or just a keypath ({32-bit
int}]{32-bit int}…) which is very likely sufficient for a HWW to derive the
relevant key without the creation of a lookup-window or other „maps".
It could even be an enciphered payload which was shared during
address/redeem-script generation and „loops“ back during a signing request.
Maybe I’m overcomplicating things, but for practical multisig with HWWs, a
simple BIP32-child-key-index or BIP32-keypath derivation support field should
be sufficient.
A generic „derivation support field“, provided from the signer to the creator
during address-generation that just „loops“ back during the PSBT use-cases is
probably a overkill.
Thanks
—
/jonas
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
