From: "Russell O'Connor" <roconnor@blockstream•io>
To: Anthony Towns <aj@erisian•com.au>
Cc: 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:18:13 -0500 [thread overview]
Message-ID: <CAMZUoK=SC3+d73SNfu7rAdwE4tcJK6jmg9-UHDJVN53ZU_HqMw@mail.gmail.com> (raw)
In-Reply-To: <20181123050330.x4xrgouit7apwk45@erisian.com.au>
[-- Attachment #1: Type: text/plain, Size: 2158 bytes --]
On Fri, Nov 23, 2018 at 12:03 AM Anthony Towns <aj@erisian•com.au> wrote:
> 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:
>
> 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:
>
Thanks for bringing this up. I was thinking the same thing as well, that
yes that should be sufficient to cover the semantics of OP_CODESEPARATOR.
Though to be more precise you would sign the position of the last
_executed_ OP_CODESEPARATOR.
That said, while I agree the above is a superior realization of the
OP_CODESEPARATOR, given that we are probably going to support
OP_CODESEPARATOR inside legacy P2SH scripts indefinitely, it is probably
better to keep the existing akward implementation of OP_CODESEPARATOR in
future versions of Script. (At least until we decide to stop mangling the
Script consensus code with more and more flag combinations and decide it is
better to cut and paste code for new versions of Script to help ensure we
don't make consensus changes to legacy behaviour).
> [0] (I think I'm going to claim "MAST" stands for "merkelized alternative
> script tree" these days, since they're not "abstract syntax trees")
>
:thumbs-up:
Sorry for hijacking the thread about OP_MASK and friends.
[-- Attachment #2: Type: text/html, Size: 2757 bytes --]
next prev parent reply other threads:[~2018-11-23 20:18 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 [this message]
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='CAMZUoK=SC3+d73SNfu7rAdwE4tcJK6jmg9-UHDJVN53ZU_HqMw@mail.gmail.com' \
--to=roconnor@blockstream$(echo .)io \
--cc=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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