To: Pieter Wuille via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
References: <CAPg+sBhGMxXatsyCAqeboQKH8ASSFAfiXzxyXR9UrNFnah5PPw@mail.gmail.com>
	<5b6b9d44-8e6c-2799-438e-d311e221bb57@satoshilabs.com>
	<CAPg+sBhNzxq0eZvnLK+k=J3pWs7zjGSGPzU8G76VeBZc3s9oOg@mail.gmail.com>
From: Tomas Susanka <tomas.susanka@satoshilabs.com>
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: <CAPg+sBhNzxq0eZvnLK+k=J3pWs7zjGSGPzU8G76VeBZc3s9oOg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: cs
Subject: Re: [bitcoin-dev] BIP 174 thoughts
Precedence: list

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 <type><optional flag><length>{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