From: "Russell O'Connor" <roconnor@blockstream•io>
To: Mark Friedenbach <mark@friedenbach•org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Version 1 witness programs (first draft)
Date: Mon, 2 Oct 2017 16:38:49 -0400 [thread overview]
Message-ID: <CAMZUoKnf5VYYKgKjcq-_vAjbStXnqr3SVZweLHak+XB975JrrQ@mail.gmail.com> (raw)
In-Reply-To: <BC800737-7B93-41BD-BA87-F25B25F95426@friedenbach.org>
[-- Attachment #1: Type: text/plain, Size: 4811 bytes --]
On Sun, Oct 1, 2017 at 4:39 PM, Mark Friedenbach <mark@friedenbach•org>
wrote:
>
> > On Oct 1, 2017, at 12:41 PM, Russell O'Connor <roconnor@blockstream•io>
> wrote:
> >
> > Creating a Bitcoin script that does not allow malleability is difficult
> and requires wasting a lot of bytes to do so, typically when handling
> issues around non-0-or-1 witness values being used with OP_IF, and dealing
> with non-standard-zero values, etc.
>
> Script validation flags of the correct place to do this. We already have
> policy validation flags that check for these things. They were not made
> consensus rules with Segwit v0 mainly due to concern over scope creep in an
> already large overhaul, of my memory is correct. Script versions and
> quadratic hashing fixes where the minimum necessary to allow segwit to
> activate safely while still enabling future upgrades that would otherwise
> have been hard forks. We knew that we would be later changing the EC
> signature scheme to be something that supported signature aggregation, and
> that would be more appropriate time to discuss such changes. As we are
> considering to do now (although witness versions means we don’t need to
> omnibus the script upgrade here either, so a v1 before signature
> aggregation is ready is fine IMHO).
>
Script validation isn't the correct place to do this. The reason is that
script operations are not aware of whether the stack items they are
processing are witness malleable items or Script computed values. Let me
take OP_IF as one example. When OP_IF operates directly on witness data,
it is subject to witness malleability, and therefore one needs to add extra
code around that to prevent witness malleability. On the other hand, when
OP_IF operates on computed data, it isn't subject to malleability and can
safely process non-zero-or-one values. If OP_IF were restricted to
requiring canonical inputs, then for the cases that OP_IF operates on
computed data, they will need to add extra code to canonicalize their
inputs. I don't think there is a correct answer here. That is because I
believe this isn't the correct place to aim to restrict witness
malleability.
OTOH, signatures are a fine place to aim to restrict witness malleability.
In fact, if signatures could securely cover all witness data, I think
everyone here would jump at the opportunity to implement that. However,
since that isn't known to be possible, we are left with doing the best we
can, which is to have signatures cover weight (or bytes). This prevents
the worst effects of witness malleability and does so without burdening
Script development. (This also requires signatures have a fixed size, so
it is understandable that signature-covers-weight wasn't included in Segwit
v0 scripts).
> In any case if there is any general witness malleability due to opcode
> semantics that it’s not fixed by one of our existing policy flags, that is
> a bug and I would encourage you to report it.
> > I'll argue that I don't want my counter-party going off and using a very
> deeply nested key in order to subvert the fee rate we've agreed upon after
> I've signed my part of the input. If we are doing multi-party signing of
> inputs we need to communicate anyways to construct the transaction. I see
> no problem with requiring my counter-party to choose their keys before I
> sign so that I know up front what our fee rate is going to be. If they
> lose their keys and need a backup, they should have to come back to me to
> resign in order that we can negotiate a new fee rate for the transaction
> and who is going to be covering how much of the fee and on which inputs.
>
> Arguing that every single user should be forced to restart an interactive
> signing session. That’s a very strong statement based on something that I
> would say is a preference that depends on circumstances.
>
> What about an optional commitment to witness size in bytes? The value zero
> meaning “I don’t care.” I would argue that it should be a maximum however,
> and therefor serialized as part of the witness. The serialization of this
> would be very compact (1 plus the difference between actual and maximum,
> with zero meaning not used.)
I would be fine your suggestion above, though I think Luke's suggestion of
having both SIGHASH_WITNESS_SIZE and SIGHASH_WITNESS_DEPTH flag is better
because it is simpler.
Those people worried about restarting interactive signing session in the
unlikely event of parties not knowing what keys they are planning to use
can use just the SIGHASH_WITNESS_DEPTH flag. Those people worried about
counterparties fiddling with fee rates can use both flags. The choice
doesn't even need to be made at script commitment time.
[-- Attachment #2: Type: text/html, Size: 5394 bytes --]
next prev parent reply other threads:[~2017-10-02 20:39 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-01 1:13 Luke Dashjr
2017-10-01 2:23 ` Mark Friedenbach
2017-10-01 2:47 ` Luke Dashjr
2017-10-01 5:04 ` Mark Friedenbach
2017-10-01 11:22 ` Felix Weis
2017-10-01 17:36 ` Luke Dashjr
2017-10-01 19:05 ` Russell O'Connor
2017-10-01 19:27 ` Mark Friedenbach
2017-10-01 19:41 ` Russell O'Connor
2017-10-01 20:39 ` Mark Friedenbach
2017-10-01 20:43 ` Luke Dashjr
2017-10-02 20:38 ` Russell O'Connor [this message]
2017-10-01 18:34 ` Mark Friedenbach
2017-10-01 21:32 ` Johnson Lau
2017-10-02 0:35 ` Mark Friedenbach
2017-10-02 2:56 ` Luke Dashjr
2017-10-02 9:09 ` Sjors Provoost
2017-10-02 0:45 ` Luke Dashjr
2017-10-05 20:33 ` Mark Friedenbach
2017-10-05 21:28 ` Russell O'Connor
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=CAMZUoKnf5VYYKgKjcq-_vAjbStXnqr3SVZweLHak+XB975JrrQ@mail.gmail.com \
--to=roconnor@blockstream$(echo .)io \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=mark@friedenbach$(echo .)org \
/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