{"type":"rich","version":"1.0","title":"Jonas Schnelli [ARCHIVE] wrote","author_name":"Jonas Schnelli [ARCHIVE] (npub1nf…3dtxs)","author_url":"https://yabu.me/npub1nfrrurat393mqymf3s26pujyn5vujlem3pzcukr5p9d4qpklngxq43dtxs","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2018-06-19\n📝 Original message:\u003e * Key-value map model or set model.\n\u003e * Ability for Combiners to verify two PSBT are for the same transaction\n\u003e * Optional signing\n\u003e * Derivation from xpub or fingerprint\n\u003e * Generic key offset derivation\n\u003e * Hex encoding?\n\nI 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.\nAFAIK things like non-hex-encoding or generic key offset derivation are extensions and would not break existing implementations.\n\nFurther thoughts on BIP174 from my side.\n\nKey derivation in multisig:\nFrom my understanding, the signers and the creator must have agreed – in advance to the PSBT use case – on a key derivation scheme.\nBIP32 derivation is assumed, but may not always be the case.\nSharing xpubs (the chaincode) may be a concern in non-trust-relationships between signer(s) and the creator (regarding Pieters xpub/fingerprint concerns).\nProviding 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.\nFrom 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.\n\nI think it could be more flexible (generic) in BIP174.\nIt 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\".\nIt could even be an enciphered payload which was shared during address/redeem-script generation and „loops“ back during a signing request.\n\nMaybe 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.\nA 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.\n\n\nThanks\n—\n/jonas\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 833 bytes\nDesc: Message signed with OpenPGP\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180619/e76fa257/attachment-0001.sig\u003e"}