đź“… 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>;
Jonas Schnelli [ARCHIVE] /
npub1nf…3dtxs
2023-06-07 18:13:03
in reply to nevent1q…vy4f
Author Public Key
npub1nfrrurat393mqymf3s26pujyn5vujlem3pzcukr5p9d4qpklngxq43dtxsPublished at
2023-06-07 18:13:03Event JSON
{
"id": "ed0b557d3844ce8bf674c3a0b570beb625e5d3c2aa0a3724dabb60c8683ebd09",
"pubkey": "9a463e0fab8963b013698c15a0f2449d19c97f3b88458e5874095b5006df9a0c",
"created_at": 1686161583,
"kind": 1,
"tags": [
[
"e",
"cde3c2f1af5ec4e3200e32c7fdbcba54b58741a9d65d38dd383e78325ee0ffcd",
"",
"root"
],
[
"e",
"c006bfccab58ddfc1ba60d11e6c6141e5ae24e6fb519c585d53ec4e10f05bba5",
"",
"reply"
],
[
"p",
"7b004e1cd14bfe95aec539b0a3843c2713d155a939abd807a5714c2a09f484c4"
]
],
"content": "📅 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",
"sig": "5af67ca8ce5d3d55abde4fcf34680991e1d7eb7a28595814830702915bfe6e22389665fafd5c70a524584db1fb96db1d206f0fc6b60e892cc285c42868569848"
}