diff options
author | Anthony Towns <aj@erisian.com.au> | 2018-12-14 10:47:29 +1000 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2018-12-14 00:47:42 +0000 |
commit | 1555e8a63c67a2813c5f25fad71f92f18eabfc64 (patch) | |
tree | e7a27da3694143b4d8a2dcbfe73faeef861eb609 /48 | |
parent | 6b19391dd17c9af534678213f1c4af650f49a872 (diff) | |
download | pi-bitcoindev-1555e8a63c67a2813c5f25fad71f92f18eabfc64.tar.gz pi-bitcoindev-1555e8a63c67a2813c5f25fad71f92f18eabfc64.zip |
Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT
Diffstat (limited to '48')
-rw-r--r-- | 48/c37120e30b768046ec1237eb60f365531ae907 | 142 |
1 files changed, 142 insertions, 0 deletions
diff --git a/48/c37120e30b768046ec1237eb60f365531ae907 b/48/c37120e30b768046ec1237eb60f365531ae907 new file mode 100644 index 000000000..c0c769dcf --- /dev/null +++ b/48/c37120e30b768046ec1237eb60f365531ae907 @@ -0,0 +1,142 @@ +Return-Path: <aj@erisian.com.au> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 04C03D9F + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 14 Dec 2018 00:47:42 +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 3D8A17A4 + for <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 14 Dec 2018 00:47:41 +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 1gXbde-0005GZ-69; Fri, 14 Dec 2018 10:47:36 +1000 +Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); + Fri, 14 Dec 2018 10:47:29 +1000 +Date: Fri, 14 Dec 2018 10:47:29 +1000 +From: Anthony Towns <aj@erisian.com.au> +To: Russell O'Connor <roconnor@blockstream.io> +Message-ID: <20181214004729.dc2ivs435bi55cdh@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> + <20181213000553.cikilodf65an225g@erisian.com.au> + <CAMZUoKkPCNaPyiSanDH8cAZuybywZsNE0ErYJTctcYc+VAWQxg@mail.gmail.com> +MIME-Version: 1.0 +Content-Type: text/plain; charset=utf-8 +Content-Disposition: inline +Content-Transfer-Encoding: 8bit +In-Reply-To: <CAMZUoKkPCNaPyiSanDH8cAZuybywZsNE0ErYJTctcYc+VAWQxg@mail.gmail.com> +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: Fri, 14 Dec 2018 13:35:36 +0000 +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Fri, 14 Dec 2018 00:47:42 -0000 + +On Thu, Dec 13, 2018 at 11:21:10AM -0500, Russell O'Connor wrote: +> 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. + +Sorry, I elided some of my reasoning. Suppose witness data wasn't +malleable; in that case any valid witness for a particular script would +have the exact same weight, and it would be good enough to just sign +the script, because that also commits to the witness weight. (And if +you're doing SIGHASH_ALL, you're committing to the exact transaction +weight too) + +I think the benefit of signing the weight is mostly that it also commits +to the feerate and hence transaction priority: you know how much you're +paying in fees when you sign, but the reason you're paying any fees is +to get a particular priority for your transaction, so if that can change +from under you because the tx weight changes, you're being ripped off +(either because you get less priority than you were paying for, or +because you get more than you wanted and would have paid less if you'd +known). + +But if, just from looking at the script, you can be sure the witness +weight will be between "w" and "w + 0.8%" and your fee is "f", you +know your feerate (and hence priority) is between "f/w - 0.8%" and +"f/w". If the "0.8%" is small enough, that's just a rounding error and +you probably have more uncertainty in your feerate estimations anyway. So +I think at that point it's reasonable to target the lower bound feerate +("f/w - 0.8%"), because your only potential loss is that you get a higher +feerate and would have saved "0.8%" on f if you'd been able to be 100% +sure of that. + +> 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. + +The cases where the tx is malleable by someone else, and you know what +the weight should be in advance, and you can't take the final tx once it +hits your mempool and fix the weight to what it should be and +rebroadcast, seem limited to me? + +Being able to commit to a minimum feerate seems like it would be more +generally useful: it would apply for ANYONECANPAY crowd-funding type +txes as well; "here's my input, and I'm paying 3 sat/vb feerate, but only +if everyone else does too!". You could do that, I think, with a rule +along the lines of: + + (a) take the actual tx feerate, f*4000/w + (b) round it down to the nearest exponent of 1.05 sat/kvbyte, + so 1.3 sat/vbyte becomes 1240.62 (1.05**146 < 1.05**147=1302) + (c) if the signature doesn't have an extra byte, then it should + commit to that exponent (146) + (d) if the signature does have an extra byte, b, then b<=146 and + the signature should commit to 146-(1+b) + +That way if you sign something that says "minimum fee rate of 0.001 sat +per vbyte", you commit to an exponent of 0, and someone else can raise the +feerate anywhere up to 265.7 sat/vb just by tweaking your signature to +indicate how much they've raised the feerate. Likewise you could commit +to some other exponent, and anyone else could adjust your signature to +remain valid for a tx with a feerate of up to 265,742 times greater than +what you expected, but never more than 5% less than what you expected. + +This seems too complicated to do any time soon; and maybe more +complicated than will ever be worthwhile, though. + +Cheers, +aj + + |