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 7761DFCA for ; Tue, 19 Jun 2018 14:25:51 +0000 (UTC) X-Greylist: delayed 00:05:41 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 A73C472E for ; Tue, 19 Jun 2018 14:25:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.sldev.cz (Postfix) with ESMTP id E207DE102D; Tue, 19 Jun 2018 14:20:06 +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 uVP5Nk9xAOM9; Tue, 19 Jun 2018 14:20:04 +0000 (UTC) Received: from [10.8.0.37] (unknown [10.8.0.37]) by mail.sldev.cz (Postfix) with ESMTPSA id D1435E0F21; Tue, 19 Jun 2018 14:20:04 +0000 (UTC) References: To: bitcoin-dev@lists.linuxfoundation.org From: matejcik 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: <5b6b9d44-8e6c-2799-438e-d311e221bb57@satoshilabs.com> Date: Tue, 19 Jun 2018 16:20:03 +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="kMJ3ihuzFtLKkwkK8nM6h3aXRJQaYZbai" 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: Tue, 19 Jun 2018 14:27:34 +0000 Subject: Re: [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, 19 Jun 2018 14:25:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kMJ3ihuzFtLKkwkK8nM6h3aXRJQaYZbai Content-Type: multipart/mixed; boundary="zecusQR03Ly0kmHBi957KPjAIu9gVenb5"; protected-headers="v1" From: matejcik To: bitcoin-dev@lists.linuxfoundation.org Cc: tomas.susanka@satoshilabs.com Message-ID: <5b6b9d44-8e6c-2799-438e-d311e221bb57@satoshilabs.com> Subject: Re: [bitcoin-dev] BIP 174 thoughts References: In-Reply-To: --zecusQR03Ly0kmHBi957KPjAIu9gVenb5 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hello, First of all, we'd like to apologize for such a late feedback, since there is a PR for this already. We've come up with a few more notes on this, so we are introducing those in this message and replying on Pieter's points in another one. 1) Why isn't the global type 0x03 (BIP-32 path) per-input? How do we know, which BIP-32 path goes to which input? The only idea that comes to my mind is that we should match the input's scriptPubKey's pubkey to this 0x03's key (the public key). If our understanding is correct, the BIP-32 path is global to save space in case two inputs share the same BIP-32 path? How often does that happen? And in case it does, doesn't it mean an address reuse which is discouraged? Also, we believe that if the public key is to be used as "spent to by an output" it should be in an output section. If the public key is to be used to sign an input, it should be in the input section. Again, how often are those the same? We understand creating another section might be cumbersome, but it'd significantly increase clarity to have global, input and output section. Alternately, we could keep =E2=80=9Cspend to=E2=80=9D public keys in the = global section, and put the input public keys to the per-input sections. This is less clear, but doesn=E2=80=99t introduce another section. A question to consi= der is, will there be more per-output data? If yes, it might make sense to have an output section. 2) The global items 0x01 (redeem script) and 0x02 (witness script) are somewhat confusing. Let's consider only the redeem script (0x01) to make it simple. The value description says: "A redeem script that will be needed to sign a Pay-To-Script-Hash input or is spent to by an output.". Does this mean that the record includes both input's redeem script (because we need to sign it), but also a redeem script for the output (to verify we are sending to a correct P2SH)? To mix those two seems really confusing. Yet again, adding a new output section would make this more readable. We would include the input=E2=80=99s redeem script in the input section and = the output=E2=80=99s redeem script again in the output section, because they=E2= =80=99ll most likely differ anyway. The rationale says that the scripts are global to avoid duplication. However, how often is this the case? The scripts include a hash of some OP codes and the recipient's public key for example. So a) how often are two scripts equal to justify this? b) if they're the same, doesn't it yet again signalize address reuse? 3) The sighash type 0x03 says the sighash is only a recommendation. That seems rather ambiguous. If the field is specified shouldn't it be binding= ? 4) Is it a good idea to skip records which types we are unaware of? We can't come up with a reasonable example, but intuitively this seems as a potential security issue. We think we should consider introducing a flag, which would define if the record is "optional". In case the signer encounters a record it doesn't recognize and such flag is not set, it aborts the procedure. If we assume the set model we could change the structure to {data}. We are not keen on this, but we wanted to include this idea to see what you think. ----------- In general, the standard is trying to be very space-conservative, however is that really necessary? We would argue for clarity and ease of use over space constraints. We think more straightforward approach is desired, although more space demanding. What are the arguments to make this as small as possible? If we understand correctly, this format is not intended for blockchain nor for persistent storage, so size doesn=E2=80= =99t matter nearly as much. Thank you, Tomas Susanka Jan Matejek --zecusQR03Ly0kmHBi957KPjAIu9gVenb5-- --kMJ3ihuzFtLKkwkK8nM6h3aXRJQaYZbai 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 iQIcBAEBCAAGBQJbKREUAAoJEMZ/sQbk7Rcehp8QAL+uP8cbG/Cet9/PsqNqkOPY 4rRf8/4m6MHFDFP2ra02ODzXRThb5dQ5Orsdu3SFpTpgP83f5I1J/DK4ZCjxfZdZ ufwgIMkuelXHHngT8gq/wjiHzh6+SgJHMBnC9u8BOLyNLHNA2+uP1NxdN+ae5ug4 vYBeaOsOFkL6b0tR4cTIkpp5kf9sc/6cTS0lE0aPToAQQ7dWlcgEJCi8hbKAl2Q5 MDrf/L/yAddrnNyME1F7Q+ECKUTn1RnF0kL7LNH1zsbvm5bjRKqic6r/NeRCkITO x1QxljiB1ZcZeN9jLFNTOPltc0SB9Ezn3Zi29hzvU7WW79QQPG7jNmjmwE6CJ4pY 9zFlyxPlwBc+cZwHvQyn6fWhpPafb37AfbuBEod9UyxJWnsgtuv7E2nhkippyWQi g0aVZvVjAMTCCwZCH52O0bXK1DX/muiXwgIfBRmJKoBLVpi09CySmhRaQUzMedqT X7ycc1xh4Aqb1BjeUalo1jPD6A64ZzayME7mGFa54i3e553IKl7HhRtlF3XEgegS Hub5E5nsNwjz42aZp3eRPJqXQiSZcquU69aR/lTGuzgRUNIrWAd+m6/bDsja7wrb eN8NMbt444ferux5F5wme682UrebszbRX7LEQAcXfyF66kNT//oSVYXYI3IYeyTG 7sW4dE8C0cPcQiE5j5WW =dmss -----END PGP SIGNATURE----- --kMJ3ihuzFtLKkwkK8nM6h3aXRJQaYZbai--