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: Thu, 13 Dec 2018 10:19:02 +1030 [thread overview]
Message-ID: <87pnu6s3v5.fsf@rustcorp.com.au> (raw)
In-Reply-To: <DAAB7568-A004-4897-B5B3-0FBBC6895246@xbt.hk>
Johnson Lau <jl2012@xbt•hk> writes:
>> On 12 Dec 2018, at 5:42 PM, Rusty Russell via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>>
>> Pieter Wuille via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> writes:
>>> Here is a combined proposal:
>>> * Three new sighash flags are added: SIGHASH_NOINPUT, SIGHASH_NOFEE,
>>> and SIGHASH_SCRIPTMASK.
>>> * A new opcode OP_MASK is added, which acts as a NOP during execution.
>>> * The sighash is computed like in BIP143, but:
>>> * If SIGHASH_SCRIPTMASK is present, for every OP_MASK in scriptCode
>>> the subsequent opcode/push is removed.
>>
>> Having the SIGHASH_SCRIPTMASK flag is redundant AFAICT: why not always
>> perform mask-removal for signing?
>
> Because a hardware wallet may want to know what exact script it is signing?
OK, removing OP_MASKs unconditionally would introduce a hole without
some explicit flag to say they've been removed (the "real script" could
be something different with OP_MASKs). We could have the signature
commit to the outputscript, but that's a bit meh.
> Masked script has reduced security, but this is a tradeoff with
> functionality (e.g. eltoo can’t work without masking part of the
> script). So when you don’t need that extra functionality, you go back
> to better security
>
> However, I’m not sure if there is any useful NOINPUT case with unmasked script.
This is *not* true of Eltoo; the script itself need not change for the
rebinding (Christian, did something change?).
So, can we find an example where OP_MASK is useful?
>> If you're signing arbitrary scripts, you're surely in trouble already?
>>
>> And I am struggling to understand the role of scriptmask in a taproot
>> world, where the alternate script is both hidden and general?
>
> It makes sure that your signature is applicable to a specific script branch, not others (assuming you use the same pubkey in many branches, which is avoidable)
If I'm using SIGHASH_NOINPUT, I'm already required to take care with key
reuse.
Without a concrete taproot proposal it's hard to make assertions, but
if the signature flags that it's using the taproot script, it's
no less safe, and more general AFAICT.
Thanks!
Rusty.
next prev parent reply other threads:[~2018-12-12 23:49 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 [this message]
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=87pnu6s3v5.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