From: Anthony Towns <aj@erisian•com.au>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT
Date: Fri, 14 Dec 2018 19:30:02 +1000 [thread overview]
Message-ID: <20181214093002.p2nvfrlaycqblww3@erisian.com.au> (raw)
In-Reply-To: <87h8fiqn1z.fsf@rustcorp.com.au>
On Thu, Dec 13, 2018 at 11:07:28AM +1030, Rusty Russell via bitcoin-dev wrote:
> And is it worthwhile doing the mask complexity, rather than just
> removing the commitment to script with NOINPUT? It *feels* safer to
> restrict what scripts we can sign, but is it?
If it's not safer in practice, we've spent a little extra complexity
committing to a subset of the script in each signature to no gain. If
it is safer in practice, we've prevented people from losing funds. I'm
all for less complexity, but not for that tradeoff.
Also, saying "I can't see how to break this, so it's probably good
enough, even if other people have a bad feeling about it" is a crypto
anti-pattern, isn't it?
I don't see how you could feasibly commit to more information than script
masking does for use cases where you want to be able to spend different
scripts with the same signature [0]. If that's possible, I'd probably
be for it.
At the same time, script masking does seem feasible, both for
lightning/eltoo, and even for possibly complex variations of scripts. So
committing to less doesn't seem wise.
> You already need both key-reuse and amount-reuse to be exploited.
> SIGHASH_MASK only prevents you from reusing this input for a "normal"
> output; if you used this key for multiple scripts of the same form,
> you're vulnerable[1].
For example, script masking seems general enough to prevent footguns
even if (for some reason) key and value reuse across eltoo channels
were a requirement, rather than prohibited: you'd make the script be
"<eltoo-channel-id> MASK <statenum> CLTV 2DROP <a+b> CHECKSIG", and your
signature will only apply to that channel, even if another channel has
the same capacity and uses the same keys, a and b.
> So I don't think it's worth it. SIGHASH_NOINPUT is simply dangerous
> with key-reuse, and Don't Do That.
For my money, "NOINPUT" commits to dangerously little context, and
doesn't really feel safe to include as a primitive -- as evidenced by
the suggestion to add "_UNSAFE" or similar to its name. Personally, I'm
willing to accept a bit of risk, so that feeling doesn't make me strongly
against the idea; but it also makes it hard for me to want to support
adding it. To me, committing to a masked script is a huge improvement.
Heck, if it also makes it easier to do something safer, that's also
probably a win...
Cheers,
aj
[0] You could, perhaps, commit to knowing the private keys for all the
*outputs* you're spending to, as well as the inputs, which comes
close to saying "I know this is a scary NOINPUT transaction, but
we're paying to ourselves, so it will all be okay".
next prev parent reply other threads:[~2018-12-14 9:30 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
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 [this message]
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=20181214093002.p2nvfrlaycqblww3@erisian.com.au \
--to=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