From: "Russell O'Connor" <roconnor@blockstream•io>
To: Anthony Towns <aj@erisian•com.au>
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:21:10 -0500 [thread overview]
Message-ID: <CAMZUoKkPCNaPyiSanDH8cAZuybywZsNE0ErYJTctcYc+VAWQxg@mail.gmail.com> (raw)
In-Reply-To: <20181213000553.cikilodf65an225g@erisian.com.au>
[-- Attachment #1: Type: text/plain, Size: 2031 bytes --]
On Wed, Dec 12, 2018 at 7:06 PM Anthony Towns <aj@erisian•com.au> wrote:
> On Tue, Dec 11, 2018 at 05:50:24PM -0500, Russell O'Connor via bitcoin-dev
> wrote:
> > 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 seems strange to me -- why wouldn't you just assume every signature
> is 65 witness bytes, and just be grateful for the prioritisation benefit
> if someone chooses a shorter signature? Your error margin is just 0.25
> vbytes per signature.
>
The issue is that the proposal is to sign the actual weight, rather than
sign an upper bound on the weight.
The problem with signing an upper bound, is that you need to specify that
upper bound someplace in the transaction, and we are out of sneaky places
to stash that data.
Signing the actual weight is easy because the total weight is implicit, but
now you need to know the total weight before signing.
> > 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?
>
> An alternative generalisation: is there a proof that all valid witnesses
> will have a weight within some small range?
>
> > 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" Script, it begins with "OP_DEPTH OP_1SUB OP_1SUB"
>
> (DEPTH 2 NUMNOTEQUAL seems like it would have been more obvious...)
>
> I think the 1SUB idea was derived from the csv_2of2_then_1 Script where
DEPTH 1SUB is shorter than DEPTH 1 NUMNOTEQUAL.
> Cheers,
> aj
>
>
[-- Attachment #2: Type: text/html, Size: 2768 bytes --]
next prev parent reply other threads:[~2018-12-13 16:21 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 [this message]
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=CAMZUoKkPCNaPyiSanDH8cAZuybywZsNE0ErYJTctcYc+VAWQxg@mail.gmail.com \
--to=roconnor@blockstream$(echo .)io \
--cc=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.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