From: matejcik <jan.matejek@satoshilabs•com>
To: Pieter Wuille <pieter.wuille@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] BIP 174 thoughts
Date: Thu, 5 Jul 2018 13:52:02 +0200 [thread overview]
Message-ID: <d1cc06c5-1d75-902a-1f2b-e5352c862fd6@satoshilabs.com> (raw)
In-Reply-To: <CAPg+sBjczKB-tvGTpsDr8qDwfh6b_8M-2AdCwHR+DSC8pwY92Q@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 5762 bytes --]
On 4.7.2018 20:35, Achow101 wrote:
> 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
(...)
> 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?
We're worried that the "pick one of non-deterministic signatures" is a
special case and that most fields don't have this property:
* conflicts in UTXOs, sighash type, redeem/witness scripts, derivation
paths, are at best a recoverable error, usually an unrecoverable error,
at worst malicious activity.
* conflict in finalized scripts, in case more than one valid
finalization exists, might indicate that the Finalizers picked different
ND signatures, or it might indicate two possible interpretations of the
transaction (see next point). Picking arbitrarily in the latter case
would be an error.
* even for partial signatures: if two Signers with the same public key
use different sighash types, the Combiner shouldn't pick the winning one
arbitrarily.
It seems generally safer to default to rejecting conflicts, and
explicitly allowing the Combiner to process them intelligently if it
understands the relevant fields.
On 4.7.2018 21:09, Pieter Wuille wrote:
> combined again may fail. So I think we should see it the other way: we
> choose the keys in such a way that picking arbitrarily is safe. If
> there really is a future extension for which it would not be the case
> that picking arbitrarily is acceptable, more data can be moved to the
> keys, and leave the actual resolution strategy to the Finalizer.
I like this explanation and I think that if nothing else, this should be
spelled out explicitly in the spec.
But I don't think it answers the above points very well.
> An alternative would be to have a fixed resolution strategy (for
> example, when combining multiple PSBTs, pick the value from the first
> one that has a particular key set), but I don't think this adds very
> much - if picking the first is fine, picking a arbitrary one should be
> fine too.
Agreed.
>> * 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.
>
> Can you envision a situation in which this is needed? In every
> scenario I can come up with, the worst that can happen is that the
> resulting signature is just invalid.
(...)
> I believe that what you're trying to accomplish is preventing signing
> something you don't understand, but that's an independent issue.
We're actually trying to prevent signing something we don't _intend_.
I agree with your response, and I also think that in technical sense,
the worst that can happen is an invalid signature. Our concern is twofold:
1. the produced signature is most likely valid, _for a different
transaction_ than the Creator intended. It is a transaction that the
Signer must have authorized, so we could argue that they would not mind
if that unintended transaction was published. Nevertheless, this opens
an attack surface.
2. defence in depth: the "worst that can happen" assumption is only
valid if the rest of the protocol does things right.
At an intersection lies an example: say there's a fork that changes
format of inputs in the network serialized tx, in a way that happens to
be invisible to PSBT (because scripts must be set to empty). To
differentiate, we add a "Fork ID", but old Signers will still produce
signatures valid on the original chain - and, importantly, this will be
invisible to users.
This is of course contrived and several mistakes would have to happen at
the same time, but that's what defence in depth is for.
> Here is (perhaps far fetched) example of why it may not be desirable
> to reject unknown fields when signing. Imagine an extension is defined
This is definitely worth taking into consideration. But I'd argue that
some way of signalling "optionalness" is a better match here.
Alternately, a pre-processor with the appropriate knowledge can strip
the new fields for a legacy Signer - that's what I expect to happen in
practice.
> I would not be opposed to having fields with an explicit flag bit that
> says "Don't sign if you don't understand this", but I expect that that
> can also be left for future extensions.
It seems safer to consider this flag be on by default, and leave it to a
future extension to allow non-mandatory fields. The worst case here is
that legacy Signers can't natively process new PSBTs (solvable by a
preprocessor) - as opposed to legacy Signers signing unintended values.
regards
m.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2018-07-05 11:52 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
2018-07-05 17:23 ` Jason Les
2018-07-04 19:09 ` Pieter Wuille
2018-07-05 11:52 ` matejcik [this message]
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=d1cc06c5-1d75-902a-1f2b-e5352c862fd6@satoshilabs.com \
--to=jan.matejek@satoshilabs$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=pieter.wuille@gmail$(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