From: Rusty Russell <rusty@rustcorp•com.au>
To: Johnson Lau <jl2012@xbt•hk>,
bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT
Date: Wed, 19 Dec 2018 11:09:26 +1030 [thread overview]
Message-ID: <87efaenydd.fsf@rustcorp.com.au> (raw)
In-Reply-To: <6DE5291C-629D-4080-9B0C-E18BEFA28B16@xbt.hk>
Johnson Lau <jl2012@xbt•hk> writes:
>> On 16 Dec 2018, at 2:55 PM, Rusty Russell via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>
>> Anthony Towns via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> writes:
>>> 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.
>>
>> There are many complexities we could add, each of which would prevent
>> loss of funds in some theoretical case.
>
> Every security measures are overkill, until someone get burnt. If these security measures are really effective, no one will get burnt. The inevitable conclusion is: every effective security measures are overkill.
>
>>
>> From practical experience; reuse of private keys between lightning and
>> other things is not how people will lose funds[1].
>
> So you argument seems just begging the question. Without NOINPUT, it is just impossible to lose money by key reuse, and this is exactly the topic we are debating.
I think we're getting confused here. I'm contributing my thoughts from
the lightning implementer's point of view; there are other important
considerations, but this is my contribution.
In *lightning* there are more ways to lose funds via secret reuse.
Meanwhile, both SIGHASH_NOINPUT and OP_MASK have the reuse-is-dangerous
property; with OP_MASK the danger is limited to reuse-on-the-same-script
(ie. if you use the same key for a non-lightning output and a lightning
output, you're safe with OP_MASK. However, this is far less likely in
practice).
I state again: OP_MASK doesn't seem to gain *lightning* any significant
security benefit.
> It does not need to be something like GetMaskedScript(GetScriptCodeForMultiSig()). After all, only a very small number of script templates really need NOINPUT. A GetMaskedScript() in a wallet is just an overkill (and a vulnerability if mis-implemented)
Our current transaction signing code is quite generic (and, if I may say
so, readable and elegant). We could, of course, special case
GetMaskedScript() for the case we need (the Eltoo examples I've seen
have a single OP_MASK at the front, which makes it trivial).
> It’s also about functionality here: as I mentioned in another reply, OP_CODESEPARATOR couldn’t function properly with NOINPUT but without OP_MASKEDPUSH
The mailing list seems a bit backed up or something; I replied to that
in the hope you can clear my confusion on that one.
> This debate happens because NOINPUT introduces the third way to lose fund with key reuse. And once it is deployed, we have to support it forever, and is not something that we could softfork it away.
A would use the same words to encourage you to create the simplest
possible implementation?
I don't think we disagree on philosophy, just trade-offs. And that's
OK.
Cheers,
Rusty.
next prev parent reply other threads:[~2018-12-19 0:39 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
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 [this message]
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=87efaenydd.fsf@rustcorp.com.au \
--to=rusty@rustcorp$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jl2012@xbt$(echo .)hk \
/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