From: "Russell O'Connor" <roconnor@blockstream•io>
To: Johnson Lau <jl2012@xbt•hk>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT
Date: Tue, 11 Dec 2018 17:50:24 -0500 [thread overview]
Message-ID: <CAMZUoKkYcXt7O39zdpz494f9Jm195mBtWyrH3siX4PBEAf8OKQ@mail.gmail.com> (raw)
In-Reply-To: <702FE74C-119C-4D14-BCD3-85C4355356A2@xbt.hk>
[-- Attachment #1: Type: text/plain, Size: 3326 bytes --]
On Sun, Dec 9, 2018 at 2:13 PM Johnson Lau <jl2012@xbt•hk> wrote:
> The current proposal is that a 64-byte signature will be used for the
> default “signing all” sighash, and 65-byte for other sighash types. The
> space saved will allow a few more txs in a block, so I think it worths
> doing. However, this also makes witness weight estimation more difficult in
> multisig cases.
>
> This idea of signing witness weight has been brought up before. I think
> the concern is the difficulty to estimate the witness weight for complex
> scripts, which need this feature most. So it will work when it is not
> needed, and will not work when it is needed.
>
> Is there any script example that witness size malleability is unavoidable?
>
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 "
<https://github.com/ElementsProject/libwally-core/blob/c6db6ccdfa54571afeeb582919240263424736a2/src/script.c#L718-L735>csv_2of3_then_2"
Script
<https://github.com/ElementsProject/libwally-core/blob/c6db6ccdfa54571afeeb582919240263424736a2/src/script.c#L718-L735>,
it begins with "OP_DEPTH OP_1SUB OP_1SUB" spending 3 vbytes to avoid any
possible witness malleability versus just taking a witness stack item to
determine the branch, costing 1 or 2 (unmalleated) vbytes. Now to be fair,
under Taproot this particular script's witness malleability problem
probably goes away. Nonetheless, I think it is fair to say that Bitcoin
Script was designed without any regard given to scriptSig/witness
malleability concerns and the result is that one is constantly fighting
against malleability issues. Short of a wholesale replacement of Bitcoin
Script, I do think that having an option for signature covers weight is one
of the best ways to address the whole problem.
Regarding your point about 64/65-byte signatures; I speculate that in most
protocols, all parties that are able to consider signing the weight, know
what sighash flags the other parties are expected to be using. However,
your point is well-taken, and if we choose to adopt the option of
signatures covering weight, we ought to make sure there exists a 65-byte
signature that performs the equivalent of a sigHashAll (of course, still
covering that particular sighash flag under the signature), to ensure that
anti-weight-malleability can be use even when the sighash flags that other
parties will use are unknown. Even with the extra vbytes in the
signatures, there may be a net weight savings by avoiding the need for
anti-malleability Script code. (It might also be reasonable to have
participants create signatures for a small range of different weight
values? (Sorry in advance to PSBT)).
[-- Attachment #2: Type: text/html, Size: 3846 bytes --]
next prev parent reply other threads:[~2018-12-11 22:50 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 [this message]
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
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=CAMZUoKkYcXt7O39zdpz494f9Jm195mBtWyrH3siX4PBEAf8OKQ@mail.gmail.com \
--to=roconnor@blockstream$(echo .)io \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jl2012@xbt$(echo .)hk \
/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