public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Pieter Wuille <pieter.wuille@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Alternative to OP_EVAL
Date: Thu, 29 Dec 2011 22:00:26 +0100	[thread overview]
Message-ID: <20111229210022.GA29974@ulyssis.org> (raw)
In-Reply-To: <20111229190838.GA29609@ulyssis.org>

On Thu, Dec 29, 2011 at 08:08:38PM +0100, Pieter Wuille wrote:
> On Thu, Dec 29, 2011 at 01:55:03AM -0500, roconnor@theorem.ca wrote:
> > Gavin asked me to come up with an alternative to OP_EVAL, so here is my 
> > proposal.
> > 
> > OP_CODEHASH Initial Proposal
> 
> If we're again brainstorming about alternatives for OP_EVAL, I'll do my own.
> 
> It is called OP_CHECKEDEVAL, and is specified as follows:

I realized this may have been needlessly complicated. All is required to achieve the
same properties (plus win half-verification by old clients) is a somewhat more
restricted OP_EVAL which:
* Does not touch the stack or altstack - it looks at the last (code-position wise)
  literal pushed (and not yet consumed by another OP_EVAL) on the stack and uses
  that as script to be executed.
* Executes its subscript in an independent environment, which inherits only the
  main stack (this allows the outer script to hide information from the
  inner script by moving it temporarily to the alt stack).
* OP_EVAL is an effective no-op for the execution state of the outer script,
  except for:
  * potentially causing failure (if the subscript doesn't parse or doesn't
    terminate succesfully)
  * popping an element from the literal-only stack

A pay-to-script-hash becomes:

  OP_EVAL OP_HASH160 <scriptHash> OP_EQUAL

and is redeemed using

  [script input] <<script>>

-- 
Pieter  



  reply	other threads:[~2011-12-29 21:00 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-29  6:55 [Bitcoin-development] Alternative to OP_EVAL roconnor
2011-12-29  8:44 ` theymos
2011-12-29 16:42   ` roconnor
2011-12-30 12:01     ` Chris Double
2011-12-30 17:19       ` roconnor
2012-01-02 15:14         ` Stefan Thomas
2012-01-02 15:59           ` Gavin Andresen
2012-01-02 16:42             ` roconnor
2012-01-02 17:10             ` Stefan Thomas
2011-12-31  9:54     ` Joel Joonatan Kaartinen
2011-12-31 17:28       ` Zell Faze
2011-12-29 16:23 ` Gavin Andresen
2011-12-29 17:01   ` roconnor
2011-12-29 17:06     ` Luke-Jr
2011-12-29 18:00     ` Gavin Andresen
2011-12-29 19:54       ` Stefan Thomas
2011-12-29 19:08 ` Pieter Wuille
2011-12-29 21:00   ` Pieter Wuille [this message]
2011-12-29 21:31   ` Alan Reiner

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=20111229210022.GA29974@ulyssis.org \
    --to=pieter.wuille@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    /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