From: "Russell O'Connor" <roconnor@blockstream•io>
To: Gregory Maxwell <gmaxwell@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT
Date: Thu, 13 Dec 2018 11:34:17 -0500 [thread overview]
Message-ID: <CAMZUoKnFCHA+6F1trmH6UYXTXfdwEA08z3q=b0trvdZqjH67qw@mail.gmail.com> (raw)
In-Reply-To: <CAAS2fgRma+Pw-rHJSOKRVBqoxqJ3AxHO9d696fWoa-sb17JEOQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2245 bytes --]
On Wed, Dec 12, 2018 at 12:26 PM Gregory Maxwell <gmaxwell@gmail•com> wrote:
> On Wed, Dec 12, 2018 at 5:15 PM Russell O'Connor via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
> > I tend to think in opposite terms. Is there a proof that any script can
> be transformed into an equivalent one that avoids witness weight
> malleability? But I admit there is a trade off: If we don't allow for
> signature covers weight, and we do need it, it will be too late to add. On
> the other hand if we add signature covers weight, but it turns out that no
> Script ever needs to use it, then we've added that software complexity for
> no gain. However, I think the software complexity is relatively low,
> making it worthwhile.
> >
> > Moreover, even if witness weight malleability is entirely avoidable, it
> always seems to come at a cost. Taking as an example libwally's proposed
> "csv_2of3_then_2"
>
> I'm largely in agreement with you-- but my difficulty in arguing for
> signing the weight is that it seemed to me that it was only easy to
> sign an upper bound because some witnesses are variable size... and
> signing an upper bound means more signalling overhead... offsetting
> the space gains for demalleating.
>
In multi-party protocols, the last person to sign knows what the total
weight is going to be (now that we have fixed sized signatures) and at
least they have the ability to sign it. They are probably motivated to
sign the weight as long as they are interested in the success of the
transaction. I suppose there could be asynchronous protocols where there
isn't a last person to sign, but that seems a bit weird. Greg, you are
probably more familiar with examples of multi-party protocols than I am.
OTOH maybe the last person to sign isn't interested in the success of the
transaction and wants to cause grief by bloating the transaction and
signing the bloated weight. I guess in such protocols, you'll have to keep
the anti-malleablity Script Code.
I totally get the idea that signing weight has a lot of issues in many
scenarios. But I still feel than on the whole it is better to make the
option available than to be forced to rely on anti-malleability Script Code
or non-consensus relay policy.
[-- Attachment #2: Type: text/html, Size: 2726 bytes --]
next prev parent reply other threads:[~2018-12-13 16:34 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-19 22:37 Pieter Wuille
2018-11-20 20:29 ` Anthony Towns
2018-11-21 11:20 ` Christian Decker
2018-11-21 17:55 ` Johnson Lau
2018-11-21 11:15 ` Christian Decker
2018-11-23 6:04 ` Anthony Towns
2018-11-23 9:40 ` Christian Decker
2018-11-24 8:13 ` Johnson Lau
2018-11-21 17:07 ` Russell O'Connor
2018-11-22 14:28 ` Johnson Lau
2018-11-22 16:23 ` Russell O'Connor
2018-11-22 20:52 ` Johnson Lau
2018-11-22 22:10 ` Russell O'Connor
2018-11-23 10:47 ` Johnson Lau
2018-11-23 5:03 ` Anthony Towns
2018-11-23 20:18 ` Russell O'Connor
2018-11-28 3:41 ` Pieter Wuille
2018-11-28 8:31 ` Johnson Lau
2018-11-29 17:00 ` Christian Decker
2018-11-29 18:29 ` Christian Decker
2018-12-06 16:57 ` Russell O'Connor
2018-12-09 19:13 ` Johnson Lau
2018-12-11 22:50 ` Russell O'Connor
2018-12-12 19:53 ` Johnson Lau
2018-12-13 16:50 ` Russell O'Connor
2018-12-13 0:05 ` Anthony Towns
2018-12-13 16:21 ` Russell O'Connor
2018-12-14 0:47 ` Anthony Towns
[not found] ` <CAAS2fgRma+Pw-rHJSOKRVBqoxqJ3AxHO9d696fWoa-sb17JEOQ@mail.gmail.com>
2018-12-13 16:34 ` Russell O'Connor [this message]
2018-12-09 22:41 ` David A. Harding
2018-12-11 15:36 ` Russell O'Connor
2018-12-11 17:47 ` David A. Harding
2018-12-12 9:42 ` Rusty Russell
2018-12-12 20:00 ` Johnson Lau
2018-12-12 23:49 ` Rusty Russell
2018-12-13 0:37 ` Rusty Russell
2018-12-14 9:30 ` Anthony Towns
2018-12-14 13:55 ` Johnson Lau
2018-12-17 3:10 ` Rusty Russell
2018-12-20 19:34 ` Johnson Lau
2018-12-20 23:17 ` Rusty Russell
2018-12-21 18:54 ` Johnson Lau
2018-12-23 4:26 ` Anthony Towns
2018-12-23 16:33 ` Johnson Lau
2018-12-24 12:01 ` ZmnSCPxj
2018-12-24 21:23 ` Johnson Lau
2018-12-16 6:55 ` Rusty Russell
2018-12-17 19:08 ` Johnson Lau
2018-12-18 4:22 ` Peter Todd
2018-12-19 0:39 ` Rusty Russell
2019-02-09 0:39 ` Pieter Wuille
2018-12-13 0:24 ` Anthony Towns
2018-11-28 0:54 Bob McElrath
2018-11-28 8:40 ` Johnson Lau
2018-11-28 14:04 ` Bob McElrath
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='CAMZUoKnFCHA+6F1trmH6UYXTXfdwEA08z3q=b0trvdZqjH67qw@mail.gmail.com' \
--to=roconnor@blockstream$(echo .)io \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=gmaxwell@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