From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 52F77E6E for ; Tue, 10 Jul 2018 12:10:16 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail.sldev.cz (mail.sldev.cz [88.208.115.66]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 91211E2 for ; Tue, 10 Jul 2018 12:10:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.sldev.cz (Postfix) with ESMTP id 569F8E12B2; Tue, 10 Jul 2018 12:10:13 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mail.sldev.cz Received: from mail.sldev.cz ([127.0.0.1]) by localhost (mail.sldev.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3LsWgh1MM4k; Tue, 10 Jul 2018 12:10:11 +0000 (UTC) Received: from [10.8.0.37] (unknown [10.8.0.37]) by mail.sldev.cz (Postfix) with ESMTPSA id 7D810E1012; Tue, 10 Jul 2018 12:10:11 +0000 (UTC) From: matejcik To: Pieter Wuille References: <881def14-696c-3207-cf6c-49f337ccf0d1@satoshilabs.com> <95137ba3-1662-b75d-e55f-893d64c76059@satoshilabs.com> Openpgp: preference=signencrypt Autocrypt: addr=jan.matejek@satoshilabs.com; prefer-encrypt=mutual; keydata= xsFNBFqFmMgBEADPJ8NULpuu0nwox/tIfo+slGfcXZLUEZstNoaY9QgNuILJRtoJ6xZy8rQf S7iQlkaZcrpMJYdZtkRHvndkceBxesCG8io6tsU+t2SK6AvaW0FG95a9shFM/U9/JVO/QmBi IuQzbiE2XTZ/JStyEp4zpuyJqX1o9gzS/4MBXwj7Rzk8u+fHI28h96HILC2a0mC+c2gJ7f5t o/w+vxFZmk06COK08W5+odb9I8mjs0uf7jgTUEFrfwi6oCoTFmSon7cOy/WTieClwF/vUKuJ DBAtsMh2rxh8IHyH8xpR+Ay/K6jUWqeb3P2csQqMXmquYG/qdaHjQgxyuoJFbn+nT6jNGVQZ MjpZkMrGnjLccecaXlgx/rZK6ElCZ1PDHKOTW7A1YY1/eG7TWYnVv1ehQLueAoqyyfiEutsK E5jGbR0AmNjCahpeK7dxj+8g8TXpVsH207xJ+mqOm5RYqlX4OzfVvcnoHhlRIOu85i4I9rWm 1u/pP6uJFnBCKtuhhbmXCxM6wF7W5U6EVW3yymsPmSoVoaR024vffE3L5jZSsDMRxY6fDXNm ljRnOpT3l3d+kMVdAM3CdDCgmV87fdo4PAaGDfnmufGue/Gp0RiLCe/Wsm4DgIIa5UK6DmzD q0B6i9y/GJSPUChzZ8y7fYzuyXdpk/13gV2NRsskg9oXJVd1vQARAQABzSZtYXRlamNpayA8 amFuLm1hdGVqZWtAc2F0b3NoaWxhYnMuY29tPsLBfQQTAQgAJwUCWoWYyAIbIwUJCWYBgAUL CQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDGf7EG5O0XHoU0D/4+fTbt4KELEtnpkirDH4mQ Vt3KtKJrI/gp/3u+r6jUWMv2V9iRFMs09GAVBmE2DkXXIlfaT1P0QfwVSpHC4k5lwKwSCSyS MUgBbQGPOiYMCgMQ+in4vjlqWWcx6jjlgxQctQHRrVG5jyi7BSb0jwG8rcYtx8SAYkN4joG/ oy2zMbq6qu+Vsl+xR5WwWF2mcUUyiVo7dSwNy+1PaeygOR9xAWkM8J42ckLfJgvyLSviBKnU 9rgg94ryEDAMNUL5yJUygQmUM/jdpyBpBycRbWMB+zIYDPVGnFj4vN8Hs9DyGUHVb2OqSW+q VPxD7U9m9z6J3NnY9HpaFX1DD8leK3TebpyYaeODY5jyk7retuLrMq+W4kJU0290xzlWa9sU wa7lTWw63pelfPUKZ+mjhSFQSZBqiuNv67CBd/UmoqMWSDrCWj+3IFQxReFbh47Wl4MUX2cK cLocYkBzDck7hH4YfK6jJ++teN6RKXr7P1y6EI25WEfJxWK9say7x/FRkNW0s98MxtOuwEsm /vHqHQQanAT4R5l+Rr7XfU7fpmH0As98qD81lc3RHbrxEXgA0ks2VuCxBWsPpzaHUFPOcE9H hsg1jSEDi/Mo6D4e2ap7FYXDgZiKye9WnSdPlVBqJxqinDDgSBv5wzKaEGQS0MKrF9myS7d0 pBSy1Dr6IWOegM7BTQRahZjIARAAwwT6h4IFvs/hmY9KHiX/GIbvybQUU71ZWYRE2KKo5E2c ZXBJj7SiDtU80bS+NCSeF2c0i4xOYgZlIYMqlgS8k1zfdBt/JHmG3tm1JgohVj+pm42RfBAF d0y05zz5wysQOw1M4WlWKZH0ameM+0/AGqspeZushWay8Q4yx1dO/6MeyPy/NwE/MKEsCOPV aN28DndN3iKOyriCQt/IhG/n6ORPRGyei3JYqxsnpW36BOmSPWJ7Qj2pFw53p5coPOEDL8mN Ique0LJZ3zVFVMa4i7HtqIEnYO+ZnKx2G8aLsHEir2pzBv6tMwlgETcUTVfK1ePN7OzhYy4q a38hMWzk0db2V+gOlAu6SuAi1ANkcPhCPUWxPIvXiNdd9iwe5gOzFy0FoZxj22rFwgUX8wcc cfWStgoE1MGE9G5zrqc01R0x7by8BOFkImAwTyJ9vq4jG+w7Npky3PhoHPgCT5knV7Q91U2I TqPOQBcMda0B+4LOaElb1sXqe44dHwcg4dMVngaea5xL7winSqU2Gtm6pqFAGut5F7JiYhPb dGUHJPMS67ONkKe5ARu/Z/r9XoFe2TxpkvNJ/+QJQ3PCiJ6ya31ij6HOIfFbZr3xlTyU/DvG SejIvDK/SnJMw+/x60bYAshYBp0uQgih1ugtoZh7cnKj3KfhlpXT0mL8rsl1QHsAEQEAAcLB ZQQYAQgADwUCWoWYyAIbDAUJCWYBgAAKCRDGf7EG5O0XHs2xD/92sa5L6gafP/rRKfo9u3/w s+7E/kKPgG4VGDeirLo8hbinCjPr0cfZ7OgDDvp0zy6lTdZc2tcHsEbiPqblzaSZimV5Y3EQ eIzz0UhY6YdDELr8pvdnB8qnOJHXgWmZTRYkRgxFOWI3v4STmOYZQ7MFv0kHBfV3htCjYTHS Qx2jQO4CTbcSEbkVwNv56OiZroabrHRf0WUSyzElf13P/MRFjUJFYYZDqc0iOWUh4QeXbFiY fLYpOCtm0nqaDdG1VD4jMpKq1FKBvTw4id1i7pONENd4BB7ytnDvKGdVI6oDnGUBsc5VUrEa h1PbbshNMbRtFigeMe8998jWhK4jQzeuDr0FSBlhxbluGfyMUgk7s6aBC9BOsdDkgtJk1Fd/ j9sWOj8Pxzc4lMQRfygm+QxxLdqa36Qh3oK+jfK7362CXlqBfb9ryerjfFGY4VqMBzQ+BFtj lYZSdVzGWlmLD9D88wzeByIZMScQPvrXSFwPO2/TuOQNCo0VHcgHpNFzeMRK2eT8bhry+dlq U+0Kxy2gQijw9j/EZlqR3w053EwUrfAAmHHeYPimXK4pc8oSw0s1A6hQO7Vc0SgblF8taFTM UhRR7xZg+l5vybAgrDYVL75b9CDscZqd7WVmZx+xU23sUG6SaxXI7PV6bPuMug0fD3SAsieu +vypQ3jCcUKGrA== Message-ID: <797d9751-9795-55e6-35c9-61532e067d27@satoshilabs.com> Date: Tue, 10 Jul 2018 14:10:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="SHk8XbGvm9sesrE3au7TLxTPxszDWZIjw" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Wed, 11 Jul 2018 01:40:20 +0000 Cc: Bitcoin Protocol Discussion Subject: [bitcoin-dev] BIP 174 thoughts X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 12:10:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --SHk8XbGvm9sesrE3au7TLxTPxszDWZIjw Content-Type: multipart/mixed; boundary="yhlbjDNZwCuPo3UVvo7XRbcrB5ja6w4h9"; protected-headers="v1" From: matejcik To: Pieter Wuille Cc: Achow101 , Bitcoin Protocol Discussion , Tomas Susanka Message-ID: <797d9751-9795-55e6-35c9-61532e067d27@satoshilabs.com> Subject: [bitcoin-dev] BIP 174 thoughts References: <881def14-696c-3207-cf6c-49f337ccf0d1@satoshilabs.com> <95137ba3-1662-b75d-e55f-893d64c76059@satoshilabs.com> In-Reply-To: --yhlbjDNZwCuPo3UVvo7XRbcrB5ja6w4h9 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 6.7.2018 00:06, Pieter Wuille wrote:> The only case where "malicious" conflicting values can occur is when > one of the Signers produces an invalid signature, or modifies any of > the other fields already present in the PSBT for consumption by > others. If this were an issue, it would be an issue regardless of the > Combiner's operation, as in topology A no Combiner is even present. > This is generally true I think - Combiners can always be replaced with > just a different (and possibly less parallel) topology of data flow. This is an interesting thesis, and also an unspoken assumption ISTM. It seems worth adding something like this to the spec: """ In general, the result of Combiner combining two PSBTs from independent participants A and B should be functionally equivalent to a result obtained from processing the original PSBT by A and then B in a sequence.= or, for participants performing fA(psbt) and fB(psbt): Combine(fA(psbt), fB(psbt)) =3D=3D fA(fB(psbt)) =3D=3D fB(fA(psbt)) """ (...) > The bottom line is that a Combiner which picks arbitrarily in case of > conflicts will never end up with something worse than what you already > need to deal with. If you disregard the case of invalid fields > (because the result will just be an invalid transaction), then any > choice the Combiner makes is fine, because all the values it can pick > from are valid. This sounds reasonable and IMHO it would be good to have a summary of this argument in the Rationale section. > If you're worried about attack surface, I don't believe rejecting > invalid fields ever matters. An attacker can always drop the fields > you don't understand before giving you the PSBT, making your behavior > identical to one where you'd have ignore those fields in the first > place. Modifying the PSBT requires an active attacker. A passive attacker could possibly sniff the invalid signatures and misuse them. Where an active attacker can likely do more than drop fields. In general, this comes down to a philosophical difference again. I'm reluctant to sign an input with unknown data, on the premise that there could be *anything* in that data; the fact that right now I can't come up with a field that would be problematic does not mean that tomorrow won't bring one. (in particular, a potential failure here is silent, invisible to the user) We are most likely to implement the "do not sign with unknown fields" rule in any case (technically a whitelist of "known OK" field types), and resolve potential problems as they arise. I raised this point mainly because I think discussing this explicitly in the spec is beneficial: a distinction between mandatory and optional fields is one way, mentioning or prescribing possible signing strategies is another. regards m. --yhlbjDNZwCuPo3UVvo7XRbcrB5ja6w4h9-- --SHk8XbGvm9sesrE3au7TLxTPxszDWZIjw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJbRKIiAAoJEMZ/sQbk7RcenMUQAIV0NP1ZcrSEycH2Dnft04Lx lpovtY6hqfWor04QB/Hs/r5idMUVWbGRYDBUBrRjA+TU+Doq7ZlOZnFFzTwemiNQ KP+ue1tS+MGxKDMQf6PJCK0ed6dy49C7IVTowKUZvE543E60cTIZwrwyTvMrhvHh tQTwA7qvj7pb/8mvK9389kbTxTt5Z7AaoMdjL/St0K+5+kwaOSkZjiuKktXHcslM LqYDSfc5qU5vSQK6ty96fHUOMk86B39Lc4X33u07LtlllGx5a2dwTFtV6hG74vpA 5ZtG+DUm7SymxofzUlRAoP198pZhoEQn8KykTnGfFFklXfZb0ly42PaM/Luumuo8 0SA6ABUiujkTtwxGXgja278OSuO9JYPXj9PcfDBfd+x3LBOwRid4oqx8a3ARRHr6 KMOM5xUoBxZAvh3koslPvTceBhKpCkRg6smeZYdMbwiesZ7H2MHEXljCtd11TisI 1zemZIeIpCCg/Qiu7c3quWzrLwzbo/h9F868UL136JeFG/7kq+k1/744tUKX2sVn 9rWbkV7DZwPR/RfJWw+iIgo8IvrDOGEiO6Nw7DUHdmnXFqsvMR5nuUCf/FzpKElK 1hV6tVy2Kt3XawJ7PpD8eYbdAAc4djWcJnmpbkX1DtOXlPM9vsOXWpLv5Cty/zVf OnFQ2SZcPqqpvzYxsO5v =ptra -----END PGP SIGNATURE----- --SHk8XbGvm9sesrE3au7TLxTPxszDWZIjw--