From: Achow101 <achow101-lists@achow101•com>
To: matejcik <jan.matejek@satoshilabs•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP 174 thoughts
Date: Wed, 04 Jul 2018 14:35:16 -0400 [thread overview]
Message-ID: <7cIbglgQM_K07YQ3dgHTMIQwC_7OXa9DeqFquUZyfuM7HnliTUiIQZuJzo753ICjzUhqh5qLKPbGBVtGGrUT5DvkB7p3YQZePDEtiWd5Xs4=@achow101.com> (raw)
In-Reply-To: <c7a4476b-8643-3ddd-723b-1ff8b8910e36@satoshilabs.com>
Hi,
On July 4, 2018 6:19 AM, matejcik <jan.matejek@satoshilabs•com> wrote:
>
>
> hello,
>
> we still have some concerns about the BIP as currently proposed - not
>
> about the format or data contents, but more about strictness and
>
> security properties. I have raised some in the previous e-mails, but
>
> they might have been lost in the overall talk about format.
>
> - Choosing from duplicate keys when combining.
>
> We believe that "choose whichever value it wishes" is not a good
>
> resolution strategy. We propose to either change this to "in case of
>
> conflicts, software MUST reject the conflicting PSBTs", or explain in
>
> more detail why picking at random is a safe choice.
You cannot simply reject PSBTs for having conflicting values for the same key. 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 that does not use deterministic
k values can sign multiple inputs but one input is missing a UTXO so it doesn'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
signatures too), you will have two keys that have different values. The different values are both
valid signatures, just with different k values since they were randomly generated instead of
deterministically. If we fail to merge these, then you could potentially have a situation where
nothing can be done with the PSBTs now, or now everyone has to resign and in some specific
order to avoid the conflict. That complicates things and is much more annoying 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 combiners to choose the
correct values in the case of conflicts. A smart combiner could, when combining redeem scripts
and witness scripts, check that the redeem scripts and witness scripts match 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?
>
> - Signing records with unknown keys.
>
> There's been some talk about this at start, but there should be a clear
>
> strategy for Signers when unknown fields are encountered. We intend to
>
> implement the rule: "will not sign an input with any unknown fields
>
> present".
>
> Maybe it is worth codifying this behavior in the standard, or maybe
>
> there should be a way to mark a field as "optional" so that strict
>
> Signers know they can safely ignore the unknown field.
I think that requiring there to be no unknowns is a safe change.
>
> And two minor points:
>
> - Fields with empty keys.
>
> This might be inferred from the definition, but is probably worth
>
> spelling out explicitly: If a field definition states that the key data
>
> is empty, an implementation MUST enforce this and reject PSBTs that
>
> contain non-empty data.
>
> We suggest adding something to the effect of:
>
> "If a key or value data in a field doesn't match the specified format,
>
> the PSBT is invalid. In particular, if key data is specified as "none"
>
> but the key contains data beyond the type specifier, implementation MUST
>
> reject the PSBT."
>
> (not sure about the languge, this should of course allow processing
>
> unknown fields)
Agreed.
>
> - "Combiner can detect inconsistencies"
>
> Added in response to this comment [1], the current wording looks like
>
> it's describing what the Combiner is capable of, as opposed to
>
> prescribing what the combiner is allowed to do.
>
> We suggest changing to something like:
>
> "For every field type that the Combiner understands, it MAY also refuse
>
> to combine PSBTs that have inconsistencies in that field, or cause a
>
> conflict when combined."
Agreed.
Andrew
next prev parent reply other threads:[~2018-07-04 18:35 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-15 23:34 Pieter Wuille
2018-06-16 15:00 ` Peter D. Gray
2018-06-19 9:38 ` Jonas Schnelli
2018-06-19 14:20 ` matejcik
2018-06-19 15:20 ` Jonas Schnelli
2018-06-21 20:28 ` Peter D. Gray
2018-06-19 17:16 ` Pieter Wuille
2018-06-21 11:29 ` matejcik
2018-06-21 17:39 ` Pieter Wuille
2018-06-21 11:44 ` Tomas Susanka
2018-06-19 14:22 ` matejcik
2018-06-21 0:39 ` Achow101
2018-06-21 14:32 ` Tomas Susanka
2018-06-21 15:40 ` Greg Sanders
2018-06-21 19:56 ` Peter D. Gray
2018-06-21 21:39 ` Gregory Maxwell
2018-06-22 19:10 ` Pieter Wuille
2018-06-22 22:28 ` Achow101
2018-06-23 17:00 ` William Casarin
2018-06-23 20:33 ` Andrew Chow
2018-06-24 8:19 ` Andrea
2018-06-24 8:28 ` Andrew Chow
2018-06-24 9:00 ` Andrea
2018-06-23 18:27 ` Peter D. Gray
2018-06-25 19:47 ` Tomas Susanka
2018-06-25 20:10 ` Jonas Schnelli
2018-06-25 20:30 ` Achow101
2018-06-26 15:33 ` matejcik
2018-06-26 16:58 ` William Casarin
2018-06-26 17:11 ` Marek Palatinus
2018-06-27 14:11 ` matejcik
2018-06-26 20:30 ` Pieter Wuille
2018-06-27 14:04 ` matejcik
2018-06-27 15:06 ` Pieter Wuille
2018-06-29 9:53 ` matejcik
2018-06-29 19:12 ` Achow101
2018-06-29 20:31 ` Peter D. Gray
2018-07-04 13:19 ` matejcik
2018-07-04 18:35 ` Achow101 [this message]
2018-07-05 17:23 ` Jason Les
2018-07-04 19:09 ` Pieter Wuille
2018-07-05 11:52 ` matejcik
2018-07-05 22:06 ` Pieter Wuille
2018-07-10 12:10 ` matejcik
2018-07-11 18:27 ` Pieter Wuille
2018-07-11 20:05 ` Gregory Maxwell
2018-07-11 20:54 ` [bitcoin-dev] BIP 174 thoughts on graphics vv01f
2018-06-26 21:56 ` [bitcoin-dev] BIP 174 thoughts Achow101
2018-06-27 6:09 ` William Casarin
2018-06-27 13:39 ` Andrea
2018-06-27 17:55 ` Achow101
2018-06-28 20:42 ` Rodolfo Novak
2018-07-05 19:20 ` William Casarin
2018-07-06 18:59 ` Achow101
2018-06-20 0:39 Jason Les
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='7cIbglgQM_K07YQ3dgHTMIQwC_7OXa9DeqFquUZyfuM7HnliTUiIQZuJzo753ICjzUhqh5qLKPbGBVtGGrUT5DvkB7p3YQZePDEtiWd5Xs4=@achow101.com' \
--to=achow101-lists@achow101$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jan.matejek@satoshilabs$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox