public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Anthony Towns <aj@erisian.com.au>
To: Russell O'Connor <roconnor@blockstream.io>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT
Date: Fri, 23 Nov 2018 15:03:30 +1000	[thread overview]
Message-ID: <20181123050330.x4xrgouit7apwk45@erisian.com.au> (raw)
In-Reply-To: <CAMZUoK==Bdn73Lc=swgf2F5_mqE84TR1GRBFhrFkn7kab4jBaw@mail.gmail.com>

On Wed, Nov 21, 2018 at 12:07:30PM -0500, Russell O'Connor via bitcoin-dev wrote:
> 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.

Would it be sufficient to sign the position within the script of the
last OP_CODESEPARATOR? That is, if your script is:

   DUP DUP CHECKSIG CODESEP CHECKSIG CODESEP CHECKSIG

with the idea being that it can be spent by providing any pub key and
three different signatures by that key, with the first sig committing
to a "codesep position" of 0, the second a "codesep position" of 4,
and the third a "codesep position" of 6? In each case, the signature
also commits to the full (possibly masked) script as well.

I think that covers all the behaviour you can currently achieve with
CODESEP (which is pretty limited since every sig effectively commits
to the full redeem script, and you can't commit to subsets of the
signature/witness), and it keeps the things you can do with the various
features a bit orthogonal:

 NOINPUT -- lets the sig apply to different transactions
 OP_MASK -- lets the different txes have variations in the script the
            sig applies to
 CODESEP -- lets you require different sigs for different parts of a
            single script
 MAST[0] -- provides alternative scripts, doesn't affect sigs
 IF/etc  -- provides control flow within a script, doesn't affect sigs

Cheers,
aj

[0] (I think I'm going to claim "MAST" stands for "merkelized alternative
     script tree" these days, since they're not "abstract syntax trees")



  parent reply	other threads:[~2018-11-23  5:03 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 [this message]
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=20181123050330.x4xrgouit7apwk45@erisian.com.au \
    --to=aj@erisian.com.au \
    --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