Date: Wed, 04 Jul 2018 14:35:16 -0400
To: matejcik <jan.matejek@satoshilabs.com>
From: Achow101 <achow101-lists@achow101.com>
Reply-To: Achow101 <achow101-lists@achow101.com>
Message-ID: <7cIbglgQM_K07YQ3dgHTMIQwC_7OXa9DeqFquUZyfuM7HnliTUiIQZuJzo753ICjzUhqh5qLKPbGBVtGGrUT5DvkB7p3YQZePDEtiWd5Xs4=@achow101.com>
In-Reply-To: <c7a4476b-8643-3ddd-723b-1ff8b8910e36@satoshilabs.com>
References: <CAPg+sBhGMxXatsyCAqeboQKH8ASSFAfiXzxyXR9UrNFnah5PPw@mail.gmail.com>
	<TGyS7Azu3inMQFv9QFn8USr9v2m5QbhDRmiOI-4FWwscUeuIB9rA7mCmZA4-kwCJOMAx92fO7XICHtE7ES_QmIYLDy6RHof1WLALskGUYAc=@achow101.com>
	<c32dc90d-9919-354b-932c-f93fe329760b@satoshilabs.com>
	<CAPg+sBhhYuMi6E1in7wZovX7R7M=450cm6vxaGC1Sxr=cJAZsw@mail.gmail.com>
	<881def14-696c-3207-cf6c-49f337ccf0d1@satoshilabs.com>
	<CAPg+sBg4MCOoMDBVQ2eZ=p3iS3dq506Jh4vUNBmmM20a6uCwYw@mail.gmail.com>
	<95137ba3-1662-b75d-e55f-893d64c76059@satoshilabs.com>
	<RdSjdFhvANrG9ve8bXVnqs68ih5_iVK11jdOAL6WoMI2358TdylR3H2SyGHQfByKwMYYOfIJIOq0l6clYf-az8_D_D-D7cByzqbyYt1nV4c=@achow101.com>
	<c7a4476b-8643-3ddd-723b-1ff8b8910e36@satoshilabs.com>
Feedback-ID: VjS95yl5HLFwBfNLRqi61OdL1ERZPmvMbZRH2ZcBR7SKVUVYPgv7VJsV9uoyC4vIfjYnW8hPXGuLTycZbh49Zw==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP 174 thoughts
Precedence: list

Hi,=E2=80=8B


On July 4, 2018 6:19 AM, matejcik <jan.matejek@satoshilabs.com> wrote:

> =E2=80=8B=E2=80=8B
>=20
> hello,
>=20
> we still have some concerns about the BIP as currently proposed - not
>=20
> about the format or data contents, but more about strictness and
>=20
> security properties. I have raised some in the previous e-mails, but
>=20
> they might have been lost in the overall talk about format.
>=20
> -   Choosing from duplicate keys when combining.
>    =20
>     We believe that "choose whichever value it wishes" is not a good
>    =20
>     resolution strategy. We propose to either change this to "in case of
>    =20
>     conflicts, software MUST reject the conflicting PSBTs", or explain in
>    =20
>     more detail why picking at random is a safe choice.

You cannot simply reject PSBTs for having conflicting values for the same k=
ey. Especially
for the Partial Signatures, you can have two signatures for the same pubkey=
 that are both
completely valid. This situation could happen, for example, if a signer tha=
t does not use deterministic
k values can sign multiple inputs but one input is missing a UTXO so it doe=
sn't sign it. So it receives
 one PSBT and signs the first input but not the second. It receives a PSBT =
for the same transaction
which has the second input's UTXO but does not have its signatures for the =
first input. The signer
would sign both inputs. When the two PSBTs are combined (suppose the first =
PSBT has other=20
signatures too), you will have two keys that have different values. The dif=
ferent values are both
valid signatures, just with different k values since they were randomly gen=
erated instead of
deterministically. If we fail to merge these, then you could potentially ha=
ve a situation where
nothing can be done with the PSBTs now, or now everyone has to resign and i=
n some specific
order to avoid the conflict. That complicates things and is much more annoy=
ing to deal with.
So a simple solution is to allow the combiner to choose any value it wants =
as it is likely that
both values are valid.

Allowing combiners to choose any value also allows for intelligent combiner=
s to choose the
correct values in the case of conflicts. A smart combiner could, when combi=
ning redeem scripts
and witness scripts, check that the redeem scripts and witness scripts matc=
h the hash provided
in the UTXO (or in the redeem script) and choose the correct redeem script =
and witness script
accordingly if there were, for some reason, a conflict there.

Can you explain why it would be unsafe for combiners to arbitrarily choose =
a value?

>    =20
> -   Signing records with unknown keys.
>    =20
>     There's been some talk about this at start, but there should be a cle=
ar
>    =20
>     strategy for Signers when unknown fields are encountered. We intend t=
o
>    =20
>     implement the rule: "will not sign an input with any unknown fields
>    =20
>     present".
>    =20
>     Maybe it is worth codifying this behavior in the standard, or maybe
>    =20
>     there should be a way to mark a field as "optional" so that strict
>    =20
>     Signers know they can safely ignore the unknown field.

I think that requiring there to be no unknowns is a safe change.

>    =20
>     And two minor points:
>    =20
> -   Fields with empty keys.
>    =20
>     This might be inferred from the definition, but is probably worth
>    =20
>     spelling out explicitly: If a field definition states that the key da=
ta
>    =20
>     is empty, an implementation MUST enforce this and reject PSBTs that
>    =20
>     contain non-empty data.
>    =20
>     We suggest adding something to the effect of:
>    =20
>     "If a key or value data in a field doesn't match the specified format=
,
>    =20
>     the PSBT is invalid. In particular, if key data is specified as "none=
"
>    =20
>     but the key contains data beyond the type specifier, implementation M=
UST
>    =20
>     reject the PSBT."
>    =20
>     (not sure about the languge, this should of course allow processing
>    =20
>     unknown fields)

Agreed.

>    =20
> -   "Combiner can detect inconsistencies"
>    =20
>     Added in response to this comment [1], the current wording looks like
>    =20
>     it's describing what the Combiner is capable of, as opposed to
>    =20
>     prescribing what the combiner is allowed to do.
>    =20
>     We suggest changing to something like:
>    =20
>     "For every field type that the Combiner understands, it MAY also refu=
se
>    =20
>     to combine PSBTs that have inconsistencies in that field, or cause a
>    =20
>     conflict when combined."

Agreed.


Andrew