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 1C1CFC0A for ; Thu, 21 Jun 2018 11:51:00 +0000 (UTC) X-Greylist: delayed 00:06:19 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 30F798A for ; Thu, 21 Jun 2018 11:50:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.sldev.cz (Postfix) with ESMTP id 2712AE102F for ; Thu, 21 Jun 2018 11:44:39 +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 L5Wiyymn4LYc for ; Thu, 21 Jun 2018 11:44:37 +0000 (UTC) Received: from [10.8.0.16] (unknown [10.8.0.16]) by mail.sldev.cz (Postfix) with ESMTPSA id 8F8FFE0650 for ; Thu, 21 Jun 2018 11:44:37 +0000 (UTC) To: Pieter Wuille via bitcoin-dev References: <5b6b9d44-8e6c-2799-438e-d311e221bb57@satoshilabs.com> 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: <2699c3ac-63a8-6de4-07d8-002d4f903213@satoshilabs.com> Date: Thu, 21 Jun 2018 13:44:37 +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 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:51:00 -0000 Hi, On 19.6.2018 19:16, Pieter Wuille via bitcoin-dev wrote: > 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). > > 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. > > However, perhaps it makes sense to get rid of the global section > entirely, and make the whole format a transaction plus per-input and > per-output extra fields. This would result in duplication in case of > key reuse, but perhaps that's worth the complexity reduction. I think having a global section with just one record (the transaction) is just fine, in case we come up with some other fields later on which would fit the global section. Otherwise I totally agree. >> 2) The global items 0x01 (redeem script) and 0x02 (witness script) are= >> somewhat confusing. Let's consider only the redeem script (0x01) to ma= ke >> 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 a= nd the >> output=E2=80=99s redeem script again in the output section, because th= ey=E2=80=99ll most >> likely differ anyway. > I think here it makes sense because there can actually only be (up to) > one redeemscript and (up to) one witnessscript. So if we made those > per-input and per-output, it may simplify signers as they don't need a > table lookup to find the correct one. That would also mean we can drop > their hashes, even if we keep a key-value model. Yes, indeed. Just to clarify: in the first sentence you mean "per output", right? There can actually only be (up to) one redeemscript and (up to) one witnessscript *per output*. >> 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 sign= er >> 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. > Originally there was at least this intuition for why it shouldn't be > necessary: the resulting signature for an input is either valid or > invalid. Adding information to a PSBT (which is what signers do) > either helps with that or not. The worst case is that they simply > don't have enough information to produce a signature together. But an > ignored unknown field being present should never result in signing the > wrong thing (they can always see the transaction being signed), or > failing to sign if signing was possible in the first place. Another > way of looking at it, the operation of a signer is driven by queries: > it looks at the scriptPubKey of the output being spent, sees it is > P2SH, looks for the redeemscript, sees it is P2WSH, looks for the > witnessscript, sees it is multisig, looks for other signers' > signatures, finds enough for the threshold, and proceeds to sign and > create a full transaction. If at any point one of those things is > missing or not comprehensible to the signer, he simply fails and > doesn't modify the PSBT. The rationale behind this was, what if at some point we come up with a PSBT record, which forbids some kind of operation or alters some behaviour. In another words, by omitting such record the signer would create a signature, which is valid, but actually signed something different than the Creator intended. > However, if the sighash request type becomes mandatory, perhaps this > is not the case anymore, as misinterpreting something like this could > indeed result in an incorrect signature. I believe this use case illustrates it quite well. Let=E2=80=99s suppose = the sighash record is binding and the Signer does not know it. The Creator creates a PSBT with sighash set SIGHASH_SINGLE. The Signer sings the transaction with SIGHASH_ALL, because they are not aware of such field. This results in a valid signature, however not what the Creator intended it to be. >> We=E2=80=99d also like to note that the =E2=80=9Cnumber of inputs=E2=80= =9D field should be >> mandatory - and as such, possibly also a candidate for outside-record = field. > 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). Agree. I'm be fine with dropping the field completely in that case. Thanks, Tomas