public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Johnson Lau <jl2012@xbt.hk>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT
Date: Sat, 22 Dec 2018 02:54:42 +0800	[thread overview]
Message-ID: <73F32BC6-751E-4F35-BE6D-B31170FC0A54@xbt.hk> (raw)
In-Reply-To: <87y38jn5z8.fsf@rustcorp.com.au>



> On 21 Dec 2018, at 7:17 AM, Rusty Russell <rusty@rustcorp.com.au> wrote:
> 
> Johnson Lau <jl2012@xbt.hk> writes:
> 
>>> But I don't see how OP_CODESEPARATOR changes anything here, wrt NOINPUT?
>>> Remember, anyone can create an output which can be spent by any NOINPUT,
>>> whether we go for OP_MASK or simply not commiting to the input script.
>>> 
>> 
>> Let me elaborate more. Currently, scriptCode is truncated at the last executed CODESEPARATOR. If we have a very big script with many CODESEPARATORs and CHECKSIGs, there will be a lot of hashing to do.
>> 
>> To fix this problem, it is proposed that the new sighash will always commit to the same H(script), instead of the truncated scriptCode. So we only need to do the H(script) once, even if the script is very big
> 
> Yes, I read this as proposed, it is clever.  Not sure we'd be
> introducing it if OP_CODESEPARATOR didn't already exist, but at least
> it's a simplfication.
> 
>> In the case of NOINPUT with MASKEDSCRIPT, it will commit to the H(masked_script) instead of H(script).
>> 
>> To make CODESEPARATOR works as before, the sighash will also commit to the position of the last executed CODESEPARATOR. So the semantics doesn’t change. For scripts without CODESEPARATOR, the committed value is a constant.
>> 
>> IF NOINPUT does not commit to H(masked_script), technically it could still commit to the position of the last executed CODESEPARATOR. But since the wallet is not aware of the actual content of the script, it has to guess the meaning of such committed positions, like “with the HD key path m/x/y/z, I assume the script template is blah blah blah because I never use this path for another script template, and the meaning of signing the 3rd CODESEPARATOR is blah blah blah”. It still works if the assumptions hold, but sounds quite unreliable to me.
> 
> My question is more fundamental.  If NOINPUT doesn't commit to the input
> at all, no script, no code separator, nothing.  I'm struggling to
> understand your original comment was "without signing the script or
> masked script, OP_CODESEPARATOR becomes unusable or insecure with
> NOINPUT."
> 
> I mean, non-useful, sure.  Its purpose is to alter signature behavior,
> and from the script POV there's no signature with this form of NOINPUT.
> But other than the already-established "I reused keys for multiple
> outputs" oops, I don't see any new dangers?
> 
> Thanks,
> Rusty.

The question I would like to ask is: is OP_CODESEPARATOR useful under taproot? Generally speaking, CODESEPARATOR is useful only with conditional opcodes (OP_IF etc), and conditional opcodes are mostly replaced by merklized scripts. I am not sure how much usability is left with CODESEPARATOR

If no one needs CODESEPARATOR, we might just disable it, and makes the validation code a bit simpler

If CODESEPARATOR is useful, then we should find a way to make it works with NOINPUT. With H(masked_script) committed, the meaning of the CODESEPARATOR position is very clear. Without H(masked_script), the meaning of the position totally relies on the assumption that “this public key is only used in this script template”.

Ignore CODESEPARATOR and more generally, I agree with you that script masking does not help in the case of address (scriptPubKey) reuse, which is the commonest type of reuse. However, it prevents replayability when the same public key is reused in different scripts


  reply	other threads:[~2018-12-21 18:55 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
     [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 [this message]
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=73F32BC6-751E-4F35-BE6D-B31170FC0A54@xbt.hk \
    --to=jl2012@xbt.hk \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=rusty@rustcorp.com.au \
    /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