Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 634A6BAF for ; Thu, 21 Jun 2018 11:29:50 +0000 (UTC) X-Greylist: from 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 58705E6 for ; Thu, 21 Jun 2018 11:29:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.sldev.cz (Postfix) with ESMTP id 497A3E1032; Thu, 21 Jun 2018 11:29:47 +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 hmCxc0aQYDWn; Thu, 21 Jun 2018 11:29:45 +0000 (UTC) Received: from [10.8.0.37] (unknown [10.8.0.37]) by mail.sldev.cz (Postfix) with ESMTPSA id 4253EE0650; Thu, 21 Jun 2018 11:29:45 +0000 (UTC) To: Pieter Wuille , Bitcoin Protocol Discussion References: <5b6b9d44-8e6c-2799-438e-d311e221bb57@satoshilabs.com> 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: <9ceaba82-d2f2-439e-bced-8f5a337566d6@satoshilabs.com> Date: Thu, 21 Jun 2018 13:29:44 +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="iqan7B78GYe3hDtZa8lr22wMAMJ4uAJ1u" 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: Thu, 21 Jun 2018 12:25:58 +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: Thu, 21 Jun 2018 11:29:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --iqan7B78GYe3hDtZa8lr22wMAMJ4uAJ1u Content-Type: multipart/mixed; boundary="Xk002DtnM0CdDBs1GBRVf97KIQSJLQh3s"; protected-headers="v1" From: matejcik To: Pieter Wuille , Bitcoin Protocol Discussion Message-ID: <9ceaba82-d2f2-439e-bced-8f5a337566d6@satoshilabs.com> Subject: Re: [bitcoin-dev] BIP 174 thoughts References: <5b6b9d44-8e6c-2799-438e-d311e221bb57@satoshilabs.com> In-Reply-To: --Xk002DtnM0CdDBs1GBRVf97KIQSJLQh3s Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 19.6.2018 19:16, Pieter Wuille wrote: >> 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). >=20 >> If our understanding is correct, the BIP-32 path is global to save spa= ce >> 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? >=20 > Yes, the reason is address reuse. It may be discouraged, but it still > happens in practice (and unfortunately it's very hard to prevent > people from sending to the same address twice). >=20 > It's certainly possible to make them per-input (and even per-output as > suggested below), but I don't think it gains you much. At least when a > signer supports any kind of multisig, it needs to match up public keys > with derivation paths. If several can be provided, looking them up > from a global table or a per-input table shouldn't fundamentally > change anything. So here=E2=80=99s a thing I=E2=80=99m still confused about. Imagine two cases, for a naive Signer: - either all data is global - or most data is per input. Now, the general signing flow is this: 1. Pre-serialize the transaction 2. Prepare the current input - fill out scriptPubKey (or equivalent for segwit) 3. find a secret key 4. output public key + signature Step (3) is the main issue here. In the case of everything per-input, the naive Signer can do this: 1. (in the global section) pre-serialize the transaction 2. (in each input) find and fill out scriptPubKey from the provided UTXO 3. (for a given BIP32 path) check if the master fingerprint matches mine, if yes, derive secret key, output pubkey, signature 4. goto 3 (more keys per input), goto 2 (next input) Note that this flow works perfectly for multisig; it=E2=80=99s going to b= e the job of a Finalizer to build the final scriptSig, but each input can have multiple partial signatures -- and, interestingly, the naive Signer doesn=E2=80=99t even need to know about multisig. A less naive Signer will want to check things, maybe derive a scriptSig itself and check if it matches the given hash, etc., but it can do this all in place. You go linearly through the signing flow and place a couple strategic assertions along the way. However, if the data is global, as is now, it gets more complicated: 1. (in the global section) pre-serialize the transaction, prefill lookup tables 2. (for a given BIP32 path) check if mine, then derive public key and store in a dictionary 3. (for each input) find _and parse_ scriptPubKey, extract (PK or) script hash 4. lookup redeem script based on script-hash; if not found, goto 2; if found, parse out public key 5. lookup public key in the BIP32 dictionary; if not found, goto 2 6. output pubkey, signature In addition to being more steps and lookups, it requires the Signer to understand the redeem script. A strict Signer will want that anyway, but in the first case, the Signer can regenerate the scripts and compare specificaly the ones it's working with; here, you need to parse them even before you know what you're comparing to. Is there something I=E2=80=99m missing? Because as I see it, there is lit= erally no advantage to the more complicated flow; that=E2=80=99s why we assumed = that the format is space-saving, because saving space was the only reason we could imagine. > If we go down this route, if a field is marked as mandatory, can you > still act as a combiner for it? Future extensions should always > maintain the invariant that a simple combiner which just merges all > the fields and deduplicates should always be correct, I think. So such > a mandatory field should only apply to signers? (...) > However, perhaps we do want to enforce at-most one UTXO per input. If > there are more potential extensions like this, perhaps a key-value > model is better, as it's much easier to enforce no duplicate keys than > it is to add field-specific logic to combiners (especially for > extensions they don't know about yet). In general, you seem to focus a lot on the role of Combiners, esp. simple Combiners. To me, that doesn=E2=80=99t look like a significant rol= e. As I envision it, a Combiner really doesn=E2=80=99t need to do anything more complicated than merge and deduplicate records, simply based on the uniqueness of the whole record. It=E2=80=99s the Finalizer=E2=80=99s job to reconstruct and validate the = result. Also ISTM if something messes up the PSBT (such as including multiple conflicting fields anywhere), it=E2=80=99s OK to leave it to Finalizer to= fail. Are the Combiners supposed to be separate from Finalizers? (Is there a risk of a Combiner passing along a bad PSBT, Finalizer rejecting it, and the other parties not finding out?) > If we go with the "not put signatures/witnesses inside the transaction > until all of them are finalized" suggestion, perhaps the number of > inputs field can be dropped. There would be always one exactly for > each input (but some may have the "final script/witness" field and > others won't). Strongly agree with this. A guarantee that number of inputs in the transaction corresponds to number of input fields for PBST looks cleaner than specifying it separately. This way we can also drop the "input index= ". > Right now, the BIP32 fields are of the form fingerprint>... >=20 > Instead, I suggest fields of the form chaincode>... >=20 > The fingerprint in this case is identical to the first 32 bit of the > Hash160 of , so certainly no information is lost by > making this change. >=20 > This may be advantageous for three reasons: > * It permits signers to have ~thousands of master keys (at which point > 32-bit fingerprints would start having reasonable chance for > collisions, meaning multiple derivation attempts would be needed to > figure out which one to use). > * It permits signers to index their master keys by whatever they like > (for example, SHA256 rather than Hash160 or prefix thereof)> * It permi= ts signers who don't store a chaincode at all, and just > protect a single private key. I like this last usecase a lot, but perhaps that's a role for a "sub-Creator"? see below. Also, is there a reason to publish the chain code, wouldn't just the public key be sufficient to accomplish all three usecases you list? I sort of dislike the notion that you need to give all this information to a possibly untrusted Creator. An aside to this in particular, I=E2=80=99ve been thinking about the requ= irement to share derivation paths and public keys with the Creator. The spec assumes that this will happen; you=E2=80=99re talking about providing ful= l xpub+chaincode too. At least, the Creator must prefill BIP32 paths and master key fingerprints. Possibly also prefill public keys in the redeem scripts? This might not be an improvement proposal, but a point worth being raised and maybe explained in the spec. Perhaps the original Creator doesn=E2=80=99t have access to this data, and delegates this to some =E2=80=9Csub-Creators=E2=80=9D - I imagine a coordinator sending a PSBT = to signing parties, each of which acts as a sub-Creator (fills out derivation paths and public keys) and a Signer (forwarding to a HWW). Some of the discussion even suggests some sort of generic =E2=80=9Ckey derivation fie= ld=E2=80=9D with arbitrary contents - fingerprint + bip32 path? xpub + chain code? derivation points? encrypted xprv? thank you for your comments regards m. --Xk002DtnM0CdDBs1GBRVf97KIQSJLQh3s-- --iqan7B78GYe3hDtZa8lr22wMAMJ4uAJ1u 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 iQIcBAEBCAAGBQJbK4woAAoJEMZ/sQbk7Rce5vUP/0ew/PET5ssURA4vlADlnRyb +nrQeEdSzZNuIHlakLzQ6rRjdM+WZXIOnRiYoIosBEabED7SvqwHiwakbPtJiBbH RFEQrEm1cSieboLewSzxqXIqcxfj5jAKpqURafEq8+Q0dBz9otjgOEky/7fK+MRl 0w+ctf2Umt5xghExR524KrbH8xmKo+0PMe6V7eitko77GjQs5cXzZJm75wgZm263 SSimlUuEB/3+vNxt2juWJlglc5cLsqo/hqs8GCyaKsZQPFcrlsQ7gsQjYdOJ+cyy tEL+jw/5hew1dbEDjdw7FGoczRHA9QzeaK5irsBpxmKKR5fEWeVbW6b/MXBXOI+v bbb4imcuhpneGWQ9MdTQLD3WadO3zHfyZxFhaSwpJxbB+ES8pI9A7TVtO+HkxUMa IoJ7bO01H47q9cI4cUhRSOI13RUW/5JPVo7OI+HKS5JOjjBqnEJVMhpGHd/jcPdx vn6D2RL3I0vg17PJD3ARKTOgwuKbY9OGyLF05wpaArAgQuWXG9NUrlt1Z60RAeuL ubXPQD0baZHYskCzRcKOl+aIA7Q8cccTfeWUN5TdJYF8NGGsfdLelkx0jWEwgbqX vjOKLmGErcREeHdC0/iw2ZskuJ/AAbGI+9L+YoyWgmR2kATux8bMiIt7GUBJfb8/ FFKuNWuM/KW0xpJC9Sfd =kiKo -----END PGP SIGNATURE----- --iqan7B78GYe3hDtZa8lr22wMAMJ4uAJ1u--