Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 26FBDBDB for ; Thu, 13 Dec 2018 00:06:06 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A8E6542D for ; Thu, 13 Dec 2018 00:06:05 +0000 (UTC) Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au) by azure.erisian.com.au with esmtpsa (Exim 4.89 #1 (Debian)) id 1gXEVr-00064O-RW; Thu, 13 Dec 2018 10:06:01 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Thu, 13 Dec 2018 10:05:53 +1000 Date: Thu, 13 Dec 2018 10:05:53 +1000 From: Anthony Towns To: Russell O'Connor , Bitcoin Protocol Discussion Message-ID: <20181213000553.cikilodf65an225g@erisian.com.au> References: <702FE74C-119C-4D14-BCD3-85C4355356A2@xbt.hk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) X-Spam-Score: -1.9 X-Spam-Score-int: -18 X-Spam-Bar: - X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Thu, 13 Dec 2018 22:09:29 +0000 Subject: Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2018 00:06:06 -0000 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 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