{"type":"rich","version":"1.0","author_name":"npub10r66s2stvnancx9axwnfc5a34asjkwkgmkq7ztm5hf30x7fa4szsv9afdw","author_url":"https://nostr.ae/npub10r66s2stvnancx9axwnfc5a34asjkwkgmkq7ztm5hf30x7fa4szsv9afdw","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2020-01-11\n📝 Original message:I am not sure that this particular task should be done with data\nembedded in PSBT itself, and not with some sort of container that\nincludes PSBT and the authentication information.\n\nThe benefit seems to be in reusing PSBT structure for compatibilty, and\nthis might be a valid way, although I do not agree with some of your\npoints. I elaborate below:\n\n\u003e 1) In the PSBT globals section, a signature over the \"source\" PSBT\n\u003e file. It would cover all the bytes of the original PSBT file, as\n\u003e it was received by the Signer.\n\nThe problem of authenticating the contents of PSBT is independent of\nthe signing action. PSBT might be altered on the path from Creator to\nSigner. Therefore you cannot always say that Signer will be an\nauthority over 'correctness' of PSBT.\n\n\u003e - At the end of the signing process, the Finalizer should check all\n\u003e the Signers have worked from the same PSBT file (assuming that's\n\u003e the flow expected)\n\nIf there is MitM, checking something at Finalizer is likely too\nlate - the party that can intercept PSBTs can finalize before the\nlegitimate Finalizer and broadcast the transaction.\n\nParticipants can work from the same PSBT file if they all receive the\nsame PSBT, and not working in chain where next particpant receives\nupdated PSBT from the previous participant. Otherwise they will need to\neither pass two files (original and updated), or work out which fields\n(key-value blobs) to remove to get the 'source' PSBT (which might not be\ntrivial with presense of proprietary and unknown fields). Even if you\nknow which key-value pairs to remove, there is no requirement for\nordering of the fields, and some signer can serialize them in different\norder after dserialize/sign/add-signatures/re-serialize operation.\n\nIntroducing additional ordering or other structure requirements over\nsimple key-value structure will add complexity to PSBT processing, and\nadding complexity on such a basic level should have really serious\nreasons, because that increases effort required for even basic\nimplementations and increases chance of bugs.\n\nIf there is some authority on the 'correctness' of 'original' PSBT\n(all particpants receive same PSBT at the start), particpants should\ncheck the signature by that authority. That authority might use\nthe key used only for authentication, and not in the tx signing.\n\nIf particpants send PSBT in chain after adding their signatures, then\neach participant can add their signature to say 'the contents\nof PSBT after my updates should match this hash'.\n\nThe signatures of previous participants in the chain most likely do not\nmatter because of difficulty of restoring the contents of PSBT as it\nwas before the previous particpant, if you do not pass _all_ the PSBTs\n(which is excessive). \n \n\u003e 2) In the output section, specifically, the last key/value pair of\n\u003e the last output of the transaction, I want to add a similar signature,\n\u003e again signed by one of the keys used in the signing process. This\n\u003e signature will cover all the bytes of the resulting (signed) PSBT\n\u003e up to that point. Because it is the last output of the output\n\u003e section, that signature will be the last few bytes of the PSBT file.\n\u003e By \"appending\" the signature in this way, it's easier to validate\n\u003e and create the signature, without blanking the signature area during\n\u003e digest step.\n\nThis will introduce unnecessary higher-level structure to PSBT for the\nreasons that I do not find strong enough for the amount of complexity\nadded.\n\nAlso, as I said above, you likely do not need more than one\nsignature - if this is 'fan-out' scheme, then participants need do\ncheck the sig of authority that created PSBT; if this is piggy-back\nchain, then only previous particpant's signature is easily verifiable.\n\n\u003e ## Next Steps\n\u003e \n\u003e I'd like to get two officially-assigned BIP-174 key numbers assigned\n\u003e for these two signatures, and then I will see that it gets added\n\u003e into Coldcard's firmware immediately. In time, other tools are\n\u003e welcome to take advantage of these checks. I will also write a BIP\n\u003e for this, and/or make an addition to BIP-174.\n\nI think you do not need to wait for officially-assigned key numbers,\nand can just implement the scheme you envision with proprietary keys,\ndocument and promote it. Then if it shows its usefulness, it will\neither become de-facto standard with your proprietary keys (and\neveryone will want to support 'Coldard PSBT auth' or whatever the name),\nor the scheme will have serious grounds to be converted to standard and\nhave non-proprietary keys assigned.\n\n// Dmitry.\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: not available\nType: application/pgp-signature\nSize: 833 bytes\nDesc: Цифровая подпись OpenPGP\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200112/1e8c2cc8/attachment-0001.sig\u003e"}