From: Anthony Towns <aj@erisian.com.au>
To: Russell O'Connor <roconnor@blockstream.io>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT
Date: Fri, 14 Dec 2018 10:47:29 +1000 [thread overview]
Message-ID: <20181214004729.dc2ivs435bi55cdh@erisian.com.au> (raw)
In-Reply-To: <CAMZUoKkPCNaPyiSanDH8cAZuybywZsNE0ErYJTctcYc+VAWQxg@mail.gmail.com>
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
next prev parent reply other threads:[~2018-12-14 0:47 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-19 22:37 [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT 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
2018-12-14 0:47 ` Anthony Towns [this message]
[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=20181214004729.dc2ivs435bi55cdh@erisian.com.au \
--to=aj@erisian.com.au \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=roconnor@blockstream.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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