{"type":"rich","version":"1.0","author_name":"npub1fgnnmg7f4wzup9hct8nv5pnd9l07wcjqdjku9ax432n4g69v4rgq7xak44","author_url":"https://nostr.ae/npub1fgnnmg7f4wzup9hct8nv5pnd9l07wcjqdjku9ax432n4g69v4rgq7xak44","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2020-01-13\n📝 Original message:I agree with Dimitry. I don't see the point of having the MiTM\nprotection within the PSBT structure itself, in addition to the fact\nthat adding new fields is largely unnecessary. In fact, I'm not quite\nsure what kind of attack you are trying to defend against with this\nproposal.\n\nIf there is a MiTM who can modify your PSBT, then they can just modify\nthe result the signed PSBT to drop the auth signatures. Furthermore, any\nmodifications to scripts or UTXOs would just result in an invalid\nsignature, so only time is wasted. But you'll just waste time anyways\nwhen you see a failed auth sig.\n\nAdditionally, when a signer processes a PSBT, it will either accept the\nPSBT and add a signature for its inputs, or reject it and do nothing.\nGiven this behavior (and I assume you aren't going to add auth sigs for\nrejected PSBTs because that doesn't make any sense), then you already\nhave a signature there that covers everything your auth signature would\ncover. So just verify those signatures instead; for any inputs with\nsignatures, everything you need to verify them are already there.\n\nLastly, IMO, if you want MiTM protection, then you should do your\nprotection with out of band communication. Just PGP sign the PSBT (or\nsomething similar) and send the signature along separately.\n\nAndrew\n\nOn 1/11/20 3:17 PM, Dmitry Petukhov via bitcoin-dev wrote:\n\u003e \n\u003e I am not sure that this particular task should be done with data\n\u003e embedded in PSBT itself, and not with some sort of container that\n\u003e includes PSBT and the authentication information.\n\u003e \n\u003e The benefit seems to be in reusing PSBT structure for compatibilty, and\n\u003e this might be a valid way, although I do not agree with some of your\n\u003e points. I elaborate below:\n\u003e \n\u003e\u003e 1) In the PSBT globals section, a signature over the \"source\" PSBT\n\u003e\u003e file. It would cover all the bytes of the original PSBT file, as\n\u003e\u003e it was received by the Signer.\n\u003e \n\u003e The problem of authenticating the contents of PSBT is independent of\n\u003e the signing action. PSBT might be altered on the path from Creator to\n\u003e Signer. Therefore you cannot always say that Signer will be an\n\u003e authority over 'correctness' of PSBT.\n\u003e \n\u003e\u003e - At the end of the signing process, the Finalizer should check all\n\u003e\u003e the Signers have worked from the same PSBT file (assuming that's\n\u003e\u003e the flow expected)\n\u003e \n\u003e If there is MitM, checking something at Finalizer is likely too\n\u003e late - the party that can intercept PSBTs can finalize before the\n\u003e legitimate Finalizer and broadcast the transaction.\n\u003e \n\u003e Participants can work from the same PSBT file if they all receive the\n\u003e same PSBT, and not working in chain where next particpant receives\n\u003e updated PSBT from the previous participant. Otherwise they will need to\n\u003e either pass two files (original and updated), or work out which fields\n\u003e (key-value blobs) to remove to get the 'source' PSBT (which might not be\n\u003e trivial with presense of proprietary and unknown fields). Even if you\n\u003e know which key-value pairs to remove, there is no requirement for\n\u003e ordering of the fields, and some signer can serialize them in different\n\u003e order after dserialize/sign/add-signatures/re-serialize operation.\n\u003e \n\u003e Introducing additional ordering or other structure requirements over\n\u003e simple key-value structure will add complexity to PSBT processing, and\n\u003e adding complexity on such a basic level should have really serious\n\u003e reasons, because that increases effort required for even basic\n\u003e implementations and increases chance of bugs.\n\u003e \n\u003e If there is some authority on the 'correctness' of 'original' PSBT\n\u003e (all particpants receive same PSBT at the start), particpants should\n\u003e check the signature by that authority. That authority might use\n\u003e the key used only for authentication, and not in the tx signing.\n\u003e \n\u003e If particpants send PSBT in chain after adding their signatures, then\n\u003e each participant can add their signature to say 'the contents\n\u003e of PSBT after my updates should match this hash'.\n\u003e \n\u003e The signatures of previous participants in the chain most likely do not\n\u003e matter because of difficulty of restoring the contents of PSBT as it\n\u003e was before the previous particpant, if you do not pass _all_ the PSBTs\n\u003e (which is excessive).\n\u003e \n\u003e\u003e 2) In the output section, specifically, the last key/value pair of\n\u003e\u003e the last output of the transaction, I want to add a similar signature,\n\u003e\u003e again signed by one of the keys used in the signing process. This\n\u003e\u003e signature will cover all the bytes of the resulting (signed) PSBT\n\u003e\u003e up to that point. Because it is the last output of the output\n\u003e\u003e section, that signature will be the last few bytes of the PSBT file.\n\u003e\u003e By \"appending\" the signature in this way, it's easier to validate\n\u003e\u003e and create the signature, without blanking the signature area during\n\u003e\u003e digest step.\n\u003e \n\u003e This will introduce unnecessary higher-level structure to PSBT for the\n\u003e reasons that I do not find strong enough for the amount of complexity\n\u003e added.\n\u003e \n\u003e Also, as I said above, you likely do not need more than one\n\u003e signature - if this is 'fan-out' scheme, then participants need do\n\u003e check the sig of authority that created PSBT; if this is piggy-back\n\u003e chain, then only previous particpant's signature is easily verifiable.\n\u003e \n\u003e\u003e ## Next Steps\n\u003e\u003e\n\u003e\u003e I'd like to get two officially-assigned BIP-174 key numbers assigned\n\u003e\u003e for these two signatures, and then I will see that it gets added\n\u003e\u003e into Coldcard's firmware immediately. In time, other tools are\n\u003e\u003e welcome to take advantage of these checks. I will also write a BIP\n\u003e\u003e for this, and/or make an addition to BIP-174.\n\u003e \n\u003e I think you do not need to wait for officially-assigned key numbers,\n\u003e and can just implement the scheme you envision with proprietary keys,\n\u003e document and promote it. Then if it shows its usefulness, it will\n\u003e either become de-facto standard with your proprietary keys (and\n\u003e everyone will want to support 'Coldard PSBT auth' or whatever the name),\n\u003e or the scheme will have serious grounds to be converted to standard and\n\u003e have non-proprietary keys assigned.\n\u003e \n\u003e // Dmitry.\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e"}