public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Johnson Lau <jl2012@xbt.hk>
To: Russell O'Connor <roconnor@blockstream.io>,
	bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT
Date: Thu, 22 Nov 2018 22:28:35 +0800	[thread overview]
Message-ID: <64A86A3A-4633-4BE2-AE09-30BD136BCC2D@xbt.hk> (raw)
In-Reply-To: <CAMZUoK==Bdn73Lc=swgf2F5_mqE84TR1GRBFhrFkn7kab4jBaw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2849 bytes --]

With MAST in taproot, OP_IF etc become mostly redundant, with worse privacy. To maximise fungibility, we should encourage people to use MAST, instead of improve the functionality of OP_IF and further complicate the protocol.


> On 22 Nov 2018, at 1:07 AM, Russell O'Connor via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> On Mon, Nov 19, 2018 at 10:22 PM Pieter Wuille via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> So my question is whether anyone can see ways in which this introduces
> redundant flexibility, or misses obvious use cases?
> 
> Hopefully my comment is on-topic for this thread:
> 
> Given that we want to move away from OP_CODESEPARATOR, because each call to this operation effectively takes O(script-size) time, we need a replacement for the functionality it currently provides.  While perhaps the original motivation for OP_CODESEPARTOR is surrounded in mystery, it currently can be used (or perhaps abused) for the task of creating signature that covers, not only which input is being signed, but which specific branch within that input Script code is being signed for.
> 
> For example, one can place an OP_CODESEPARATOR within each branch of an IF block, or by placing an OP_CODESEPARATOR before each OP_CHECKSIG operation.  By doing so, signatures created for one clause cannot be used as signatures for another clause.  Since different clauses in Bitcoin Script may be enforcing different conditions (such as different time-locks, hash-locks, etc), it is useful to be able to sign in such a way that your signature is only valid when the conditions for a particular branch are satisfied.  In complex Scripts, it may not be practical or possible to use different public keys for every different clause. (In practice, you will be able to get away with fewer OP_CODESEPARATORS than one in every IF block).
> 
> One suggestion I heard (I think I heard it from Pieter) to achieve the above is to add an internal counter that increments on every control flow operator, OP_IF, OP_NOTIF, OP_ELSE, OP_ENDIF, and have the signature cover the value of this counter.  Equivalently we divide every Bitcoin Script program into blocks deliminated by these control flow operator and have the signature cover the index of the block that the OP_CHECKSIG occurs within.  More specifically, we will want a SigHash flag to enables/disable the signature covering this counter.
> 
> There are many different ways one might go about replacing the remaining useful behaviour of OP_CODESEPARATOR than the one I gave above. I would be happy with any solution.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


[-- Attachment #2: Type: text/html, Size: 3989 bytes --]

  reply	other threads:[~2018-11-22 14:28 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 [this message]
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
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=64A86A3A-4633-4BE2-AE09-30BD136BCC2D@xbt.hk \
    --to=jl2012@xbt.hk \
    --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