Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 3FFCDCC0 for ; Thu, 21 Jun 2018 14:32:12 +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 62ECA732 for ; Thu, 21 Jun 2018 14:32:11 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.sldev.cz (Postfix) with ESMTP id B0B3CE1030 for ; Thu, 21 Jun 2018 14:32:09 +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 IPdXA-m4baFC for ; Thu, 21 Jun 2018 14:32:08 +0000 (UTC) Received: from [10.8.0.16] (unknown [10.8.0.16]) by mail.sldev.cz (Postfix) with ESMTPSA id 1D994E0F78 for ; Thu, 21 Jun 2018 14:32:08 +0000 (UTC) To: Achow101 via bitcoin-dev References: From: Tomas Susanka Openpgp: preference=signencrypt Autocrypt: addr=tomas.susanka@satoshilabs.com; prefer-encrypt=mutual; keydata= xsFNBFnSDNoBEACvDIbCm85qgyNTEl7PkHq5nv50DIg7LSOz6dkkmCPdFLLUV0+Yz0kJGbbQ 0GiVBh+emQu6zu4bumo7+9yWM/70Ak06jnlePqIAMYw+FTqeMRvDBVDnTsVzHA2zBO9CI3/q wEbWyhijztjFmtt1QZpCdqS/cAiumUrYK9/TR9yQDCIfGcbqDY3C692phLtupR8Injpebr63 0Pvll6PB2I7ESqM5RRYfm1yzJIqjFxsF9tUPSnEOSJJ9fxa2SdC5fqAKvFC/O/QCnh5/PIm5 uS/v9r9ulu7bmSKztjRSC2p75HSD6Vg6RjADlRUIuS8HFrKJjryHhlal2DnpVnPX6Dv/G8up hWq/NKuM/FNlonOJgttf0syyoBT6mVSVXz+oTAnxUCWPoAGO1qg07Is1hLRga3cJM3ND+bHw TlNAMAV44/Gm8Lt82TOQKVPo/d/GMv1VPEGG131Yz9jO3juCh3I4Z5+3joRVS+bDit0TP5O7 wB1O94szSWKkOOZxhY93dzGE/lIt6ASXR6aBB6JE95PBc97cX380Dew7VB4d2UwYkuAtqHmu g0vFjOyjVJuxHLYBMFKsocvNQFxmBfWpAficvJvNwihCykOdSdF3woa9vFaDNkjpz+oc6uzN iTvxLoQoiXWRzUs4Zm5qVxuiCe6P87ICZQic6n2fv5rcZCU84QARAQABzS1Ub21hcyBTdXNh bmthIDx0b21hcy5zdXNhbmthQHNhdG9zaGlsYWJzLmNvbT7CwZQEEwEIAD4WIQQx60xcC8hh 5pSytXZaMf+ev00EzAUCWdIM2gIbIwUJCWYBgAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAK CRBaMf+ev00EzGaWD/99dV6WKHzftbKdoitIUUEXzaXAXy1/llRGQcuY5LSb497zNDvLtSpn 09fH9k4ofH7nTYVGqgPD3E92P02ERXb3kmVbgsqpf4JNjMU7khzZGANpRh+X6u7cN4enSQ3N BzKyjgDllnQspwBsvHEKmTYySKj6DTyvZGoABwLZlaHwJblqy1xJEmk77m68LBASa0LiMOMa TbHUJmeSF/hq+q/eY5p3ULk94G3nqpGELi7FMc80HvjR6aE7TNZcXqhtc9/TArdPk4t9sA2I 3H0fiF1gkgApu09pXXhFQP2e94ebWvFvwMPTOHB6my5objdZrutUv91FsWs3MntaHBDjOA0L aI8Y5N0xWgQMXE8WD35a1Ed7qkGHdsiCfEyzI43qQkhCMdenr7ZesV33fhp+drPoRF1nOJVV TihBfa0qZM7mZOIo0bppvl/tfRiyU3AZqP0Xl8vh60Z1YbzROfC82U168nepIQkNF0U9giEs fc0or9lcxukyljHFyavacC2FyCsbOP9gfMoLzJe2Igg0NKB4zZYW2SJJllirDOHmpWk0x98b uAuQFJ6rxDZbxM//cUf5lyqRgGlLr2R6UlqbAglZ8VpOy3mU8Nnu9pIk5C5+vV+mn7Rq4DaM o3LI4eCnr+G9w0lkeRedmlIYRjc476fVJdud1oUGeKXZTXd27iFNEM7BTQRZ0gzaARAApuUx h/b2pJufTrIx1YvghnKWZqM74xV0bq+/8VDTRIAeiqLW9qX30l/QsUqdhT+FeZZIGgHfLXJc nrIpBJqKqtfCMXsSYMBZLzt+I7fn1ULvNm6ZbxcWpKRMvjhFYk1+PD/tSgxyUTlI5TM/7gH0 DvHN20BhtWFAejRBuvVlRSUpBctpQzN0UihKQyEEflY7ok+e0Sv/BtQA1/eZGYAzuHbEng9l cLhoAZYfPmXceD0YfMu9hdDJmhFiLAjHGz8EqfJyAs6ivt/6X92gxInf8qMD+ikFOaI8GpO5 dCUh0cZPyxVycR9qccqqPwCusOPzighzRNodYhA/ggNtJHy2MFz8P6eDY1VLsXLcOF/DZ/Hg 61uFuIGEOMXwpa1QE3lC5TD3osDcIM7Hire3yFWV/MV/x5qp76cMJU6J6FInTk3q9CjVfpyG Kt2mDkuyL7Tf5W51IEcHb6+oQUdisVuc8zKAiMmXbZrBftk4JgfoJyuf0Q6J57Nb3qSVeN/8 0v8CS2Xf0pMKrVa1TGHpQOSV3+GL/FEoeJ7E6mLxsOGCWD4X2x14jTQIPdjIlaWy1QQUtCrF pAqi4mj3gndSsab4XQn+E9WGu9fUHWsKf7ssYkX9//S0e8QnPF9YcWjC1E+87s8RHc3+1CJW RRCo6jk4uO6qZrPt4kuBO2ksOvYuFiMAEQEAAcLBfAQYAQgAJhYhBDHrTFwLyGHmlLK1dlox /56/TQTMBQJZ0gzaAhsMBQkJZgGAAAoJEFox/56/TQTMazgQAK4nbHD5OiLO0iFQe6iN/gpX t46BQjYo0GJSpnJEshqF4XAwbMdZ80QfHLY1ShKDv1vFEJX8LSTEsrueNd0beeAQ1LRSW6Fx w6nBzE1QuM6TqtxZen0z4A5wH6DLouQ9zVTdb4lBSY9prlZp8OKeLFuPRLoPu5zN715awXgu sesh6upNtvTua4EFLEcqGH43e1msPj0HWOJ0EKIkdajoPD6krnNolZGnYSCiAhayEAaUmabj ZbiJwj5HM1cLGj/tmDJYgk35tfAiy/3HIcok/23ndaXGglzh49Cp/M5NHruKlEaWmXtG/D3x eSpS/BgE96uuhMUtZx0QJwG+KW/fHDAkHgx/aPH54mtdfG08kbZMhbj0Hc/oWrJpSId+4xoy 6Gwvskx5ZAWnXwuGARGnPHrLCxPQ7gbStu/6FG8c/3c0Gsd8ToFIJjmLaUi8BN1JfKscDADK l4SFM6PNVTSlcSyi821Tv0sc3c/6OOfO3zSdq1/xrXc+vWQJSghhWHbuaCXTUxT5BoPeVHbp CikOKts/7QdrOCYA5XbCeP1BsiEYz6NwV1QXzn6/6gBfHFDMSXSPih98n4mhIpsw3v2wJRco aSf3kveBq8gULnOlEnrqyh/sUtdDd5xlXifUslSFDltVumygxffY8da22e9uHKwb6JalvA1h btmov0pL2yb9 Message-ID: <21a616f5-7a17-35b9-85ea-f779f20a6a2d@satoshilabs.com> Date: Thu, 21 Jun 2018 16:32:07 +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: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: cs 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 14:34:03 +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 14:32:12 -0000 Hello, First of all, let me thank you for all the hard work you and others have put into this. On 21.6.2018 02:39, Achow101 via bitcoin-dev wrote: > While I agree that the BIP itself should be revised to reflect these su= ggestions, I fear that it may be too late. I know of a few other develope= rs who have implemented BIP 174 already but have not yet responded to thi= s email. We do realize that this discussion should have happened earlier, however agreeing on a good standard should be the number one priority for all the parties involved. The fact that someone already implemented this is indeed unfortunate, but I don't think we should lower our demands on the standard just because of a bad timing. >> A question to consider is, >> will there be more per-output data? If yes, it might make sense to hav= e >> an output section. > I think it is unlikely that there would be anymore per-output data. Hmm, upon further reflection, maybe it's not even worth including *any* per-output data, aside from what the original transaction contains. The output redeem script is either: - unknown, because we have received only an address from the receiver - or it is known, because it is ours and in that case it doesn=E2=80=99t = make sense to include it in PSBT We got stuck on the idea of the Creator providing future (output) redeem/witness scripts. But that seems to be a minority use case and can be solved efficiently via the same channels that coordinate the PSBT creation. Sorry to change opinions so quickly on this one. > >> 3) The sighash type 0x03 says the sighash is only a recommendation. Th= at >> seems rather ambiguous. If the field is specified shouldn't it be bind= ing? > I disagree. It is up to the signer to decide what they wish to sign, no= t for the creator to specify what to sign. The creator can ask the signer= to sign something in a particular way, but it is ultimately up to the si= gner to decide. This seems very ambiguous. The Signer always has the option of not signing. *What* to sign is a matter of coordination between the parties; otherwise, you could make all the fields advisory and let anyone sign anything they like? We don't understand the usecase for a field that is advisory but not binding. On what basis would you choose to respect or disregard the advisory field? Either one party has a preference, in which case they have to coordinate with the other anyway - or they don't, in which case they simply leave the field out. > Size is not really a constraint, but we do not want to be unnecessarily= large. The PSBT still has to be transmitted to other people. It will lik= ely be used by copy and pasting the string into a text box. Copying and p= asting very long strings of text can be annoying and cumbersome. So the g= oal is to keep the format still relatively clear while avoiding the dupli= cation of data. I agree. Just to put some numbers on this: if we expect a 5-part derivation path, and add the master key fingerprint, that is 4 + 5*4 =3D 24 bytes (~32 base64 letters) per input and signer. I'd argue this is not significant. If we used full xpub, per Pieter's suggestion, that would grow to 32 + 32 + 5*4 =3D 84 bytes (~112 letters) per input/signer, which is quite a l= ot. On the other hand, keeping the BIP32 paths per-input means that we don't need to include the public key (as in the lookup key), so that's 32 bytes down per path. In general, all the keys can be fully reconstructed from their values: redeem script key =3D hash160(value) witness script key =3D sha256(value) bip32 key =3D derive(value) The one exception is a partial signature. But even in that case we expect that a given public key will always correspond to the same signature, so we can act as if the public key is not part of the "key". In other words, we can move the public key to the value part of the recor= d. This holds true unless there's some non-deterministic signing scheme, *and* multiple Signers sign with the same public key, which is what Pieter was alluding to on Twitter (https://twitter.com/pwuille/status/1002627925110185984). Still, I would argue (as he also suggested) that keeping the format more complex to support this particular use case is probably not worth it. Also, we can mostly ignore deduplication of witness/redeem scripts. These still need to be included in the resulting transaction, duplicated if necessary, so I think counting their repetition against the size of PSBT isn't worth it. Best, Tomas