{"type":"rich","version":"1.0","author_name":"npub10vqyu8x3f0lfttk98xc28ppuyufaz4df8x4aspa9w9xz5z05snzq7t058y","author_url":"https://nostr.ae/npub10vqyu8x3f0lfttk98xc28ppuyufaz4df8x4aspa9w9xz5z05snzq7t058y","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2020-01-11\n📝 Original message:## Background\n\nPSBT files in transit are at risk of MiTM changes. This isn't\nsupposed to matter, but as another layer of defence, I would like\nto add two signatures to PSBT files when they are processed by the\nPSBT Signer. These additional fields would be optional, and should\npass through existing PSBT processors transparently, assuming they\npass unknown key/values as BIP-174 specifies.\n\n## Additional Key/Values\n\n1) In the PSBT globals section, a signature over the \"source\" PSBT\nfile. It would cover all the bytes of the original PSBT file, as\nit was received by the Signer. The key used for the signature may\nbe any one the keys that the Signer applied during its transaction\nsigning process. (This is flexible so that the Signer can make the\nsignature at any point in the signing process. On the Coldcard, we\nwould probably use the first key that we used for signing, so the\nfirst key involved in the first input.)\n\nThe \"key\" of the global value will be pubkey value of the key which\nwas selected by the Signer.  If its BIP32 derivation is needed for\nsome reason, that is documented in the input section already.\n\nThe \"value\" will be 65(?) bytes of a standard Bitcoin signature.\nThe digest (hash) of the source PSBT is not provided, so any tool\nthat wants to verify this signature will need to have a copy of the\noriginal PSBT. (I see that as a critical feature, not a limitation).\n\n2) In the output section, specifically, the last key/value pair of\nthe last output of the transaction, I want to add a similar signature,\nagain signed by one of the keys used in the signing process. This\nsignature will cover all the bytes of the resulting (signed) PSBT\nup to that point. Because it is the last output of the output\nsection, that signature will be the last few bytes of the PSBT file.\nBy \"appending\" the signature in this way, it's easier to validate\nand create the signature, without blanking the signature area during\ndigest step.\n\n## Role-Based View\n\nThe above additions can only be made by a PSBT processor in the Signer\nrole. No-one else has the keys needed. As for the other PSBT roles:\n\n- Any tool that reads in a PSBT and finds a signature in the final output\n  section can and should verify it:\n    - check signature over a digest of the PSBT file up to the last X bytes\n    - file must end at that point, with only the signature following it\n    - also check the key used for signature is one of the input's keys\n\n- PSBT processors in the \"combining\" role, should preserve the\nsignatures in the global section, accumulating them into the next\nPSBT. (Of course they should validate them, if they have the original\nPSBT on hand as well, but that's optional and could be done later\nin the flow.) The Combiner should always check a signed PSBT was\nnot modified in transit via the signature in the final output\nsection, and then strip it out of the combined PSBT.\n\n- At the end of the signing process, the Finalizer should check all\nthe Signers have worked from the same PSBT file (assuming that's\nthe flow expected), or the appropriate PSBT if it's a more complex\ncase. If the Finalizer is working on a file directly from a Signer,\nthen it can verify the signature in the output section as well.\n\n## Open Questions\n\nFor the message digest, I propose simple SHA256(SHA256(bytes of PSBT)).\nI'm not sure of the best way to serialize the signature, but to be\nconsistent with the rest of the file, it should probably be DER-encoded\nand variable length.\n\n## Next Steps\n\nI'd like to get two officially-assigned BIP-174 key numbers assigned\nfor these two signatures, and then I will see that it gets added\ninto Coldcard's firmware immediately. In time, other tools are\nwelcome to take advantage of these checks. I will also write a BIP\nfor this, and/or make an addition to BIP-174.\n\nI think with these changes, and assuming all the tools are verifying\nproperly, we can shutdown undetectable MiTM changes to PSBT contents.\n\n---\nPeter D. Gray  ||  Founder, Coinkite  ||  Twitter: @dochex  ||  GPG: A3A31BAD 5A2A5B10\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 529 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200111/51fab912/attachment.sig\u003e"}