Date: Thu, 13 Dec 2018 10:05:53 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Russell O'Connor <roconnor@blockstream.io>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20181213000553.cikilodf65an225g@erisian.com.au>
References: <CAPg+sBhuPG-2GXc+Bp0yv5ywry2fk56LPLT4AY0Kcs+YEoz4FA@mail.gmail.com>
	<CAPg+sBiu0BjZEtz-t7m3M+TnAEDG_k1GKtxwkOKh6qrSezUO7g@mail.gmail.com>
	<CAMZUoKkJdU0P_dVRvHn5zY6xUHYUptdK221ioQMp3FXZAerp3Q@mail.gmail.com>
	<702FE74C-119C-4D14-BCD3-85C4355356A2@xbt.hk>
	<CAMZUoKkYcXt7O39zdpz494f9Jm195mBtWyrH3siX4PBEAf8OKQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAMZUoKkYcXt7O39zdpz494f9Jm195mBtWyrH3siX4PBEAf8OKQ@mail.gmail.com>
User-Agent: NeoMutt/20170113 (1.7.2)
Subject: Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT
Precedence: list

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.

> 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...)

Cheers,
aj