rich1.0Jonas Schnelli [ARCHIVE] (npub1nf…3dtxs)https://yabu.me/npub1nfrrurat393mqymf3s26pujyn5vujlem3pzcukr5p9d4qpklngxq43dtxsnjumphttps://yabu.me📅 Original date posted:2018-06-19 📝 Original message:> * 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180619/e76fa257/attachment-0001.sig>