From: Gavin Andresen <gavinandresen@gmail•com>
To: Stefan Thomas <moon@justmoon•de>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Alternative to OP_EVAL
Date: Mon, 2 Jan 2012 10:59:00 -0500 [thread overview]
Message-ID: <CABsx9T3gNNmPen=WtCpG8RCChSwpJ73r7WU2Kz_fP31wAQ+jQg@mail.gmail.com> (raw)
In-Reply-To: <4F01C9D8.10107@justmoon.de>
Here are my latest thoughts on a safer OP_EVAL alternative, inspired
by all the ideas and agitated IRC and email
discussions of the last week or so:
Goal: Let users publish a short "funding address" that is the hash of
an arbitrary redemption Script revealed when they spend the funds,
implemented in a backwards-compatible-in-the-blockchain way.
Proposal:
A new 'standard' transaction type, "pay to Script hash":
scriptPubKey: HASH160 <push-20-byte-hash> EQUAL
Redeemed with the same scriptSig as the OP_EVAL proposal:
<signatures> <serialized Script>
Old clients/miners will ignore <signatures> and just validate that the
hash of <serialized Script> matches.
New clients/miners will recognize the new type of transaction and will
do the following additional validation:
1. Fail validation if there were any operations other than "push data"
in the original scriptSig.
2. Deserialize the top (last) item on the scriptSig stack (fail
validation if it fails to deserialize properly).
3. Run an additional validation on the deserialized script, using the
remaining items on the scriptSig stack and the deserialized script as
the scriptPubKey.
---------------
As Amir said in IRC chat today, "the idea is a hack.... but I like it."
I like it, too-- it is cleaner than OP_EVAL, more straightforward to
implement, and pretty much exactly matches the feature I care about
(moving code from the scriptPubKey to the scriptSig). There are no
special cases like "CODESEPARATORS not allowed in <serialized
script>".
--
--
Gavin Andresen
next prev parent reply other threads:[~2012-01-02 15:59 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-29 6:55 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 [this message]
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
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='CABsx9T3gNNmPen=WtCpG8RCChSwpJ73r7WU2Kz_fP31wAQ+jQg@mail.gmail.com' \
--to=gavinandresen@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=moon@justmoon$(echo .)de \
/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