summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorStefan Thomas <moon@justmoon.de>2012-01-02 18:10:25 +0100
committerbitcoindev <bitcoindev@gnusha.org>2012-01-02 17:10:41 +0000
commit09a14303d748dce2e3f196df589a589d1bc9e1a6 (patch)
treed8f5d6eb4dbe3a6585f45d994f6a3191c6b5fc0d
parent77c1ad7f21ecdc349cad5b97c88e0dac466f9607 (diff)
downloadpi-bitcoindev-09a14303d748dce2e3f196df589a589d1bc9e1a6.tar.gz
pi-bitcoindev-09a14303d748dce2e3f196df589a589d1bc9e1a6.zip
Re: [Bitcoin-development] Alternative to OP_EVAL
-rw-r--r--10/9a819be03c0c5585300d85eecaf3db0f1e6b3b123
1 files changed, 123 insertions, 0 deletions
diff --git a/10/9a819be03c0c5585300d85eecaf3db0f1e6b3b b/10/9a819be03c0c5585300d85eecaf3db0f1e6b3b
new file mode 100644
index 000000000..94ae908a6
--- /dev/null
+++ b/10/9a819be03c0c5585300d85eecaf3db0f1e6b3b
@@ -0,0 +1,123 @@
+Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
+ helo=mx.sourceforge.net)
+ by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
+ (envelope-from <moon@justmoon.de>) id 1RhlPF-0006GK-Uh
+ for bitcoin-development@lists.sourceforge.net;
+ Mon, 02 Jan 2012 17:10:41 +0000
+X-ACL-Warn:
+Received: from sulfur.webpack.hosteurope.de ([217.115.142.104])
+ by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
+ id 1RhlPE-00015Q-Ey for bitcoin-development@lists.sourceforge.net;
+ Mon, 02 Jan 2012 17:10:41 +0000
+Received: from 84-72-69-153.dclient.hispeed.ch ([84.72.69.153]
+ helo=[192.168.0.21]); authenticated
+ by sulfur.webpack.hosteurope.de running ExIM with esmtpsa
+ (TLSv1:AES256-SHA:256)
+ id 1RhlP8-0001VJ-Bh; Mon, 02 Jan 2012 18:10:34 +0100
+Message-ID: <4F01E501.3070605@justmoon.de>
+Date: Mon, 02 Jan 2012 18:10:25 +0100
+From: Stefan Thomas <moon@justmoon.de>
+User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
+ rv:8.0) Gecko/20111105 Thunderbird/8.0
+MIME-Version: 1.0
+To: bitcoin-development@lists.sourceforge.net
+References: <alpine.LRH.2.00.1112290111310.22327@theorem.ca>
+ <1325148259.14431.140661016987461@webmail.messagingengine.com>
+ <alpine.LRH.2.00.1112291135040.22327@theorem.ca>
+ <CALn1vHHjY6Qq0zEUcWaNzm_eP_JekjrK26zMXfcrfPSydwSKig@mail.gmail.com>
+ <alpine.LRH.2.00.1112301214380.9419@theorem.ca>
+ <4F01C9D8.10107@justmoon.de>
+ <CABsx9T3gNNmPen=WtCpG8RCChSwpJ73r7WU2Kz_fP31wAQ+jQg@mail.gmail.com>
+In-Reply-To: <CABsx9T3gNNmPen=WtCpG8RCChSwpJ73r7WU2Kz_fP31wAQ+jQg@mail.gmail.com>
+Content-Type: text/plain; charset=ISO-8859-1; format=flowed
+Content-Transfer-Encoding: 7bit
+X-bounce-key: webpack.hosteurope.de;moon@justmoon.de;1325524240;19b8f7ba;
+X-Spam-Score: 1.1 (+)
+X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
+ See http://spamassassin.org/tag/ for more details.
+ 1.1 AWL AWL: From: address is in the auto white-list
+X-Headers-End: 1RhlPE-00015Q-Ey
+Subject: Re: [Bitcoin-development] Alternative to OP_EVAL
+X-BeenThere: bitcoin-development@lists.sourceforge.net
+X-Mailman-Version: 2.1.9
+Precedence: list
+List-Id: <bitcoin-development.lists.sourceforge.net>
+List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
+ <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
+List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
+List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
+List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
+List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
+ <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
+X-List-Received-Date: Mon, 02 Jan 2012 17:10:42 -0000
+
++1. I love this proposal.
+
+It's two less bytes than OP_EVAL even.
+It allows static analysis.
+It doesn't require any change to the script interpreter. (You can do a
+static replacement step between parsing and execution.)
+It allows all urgent use cases.
+It doesn't consume a NOP. If we ever want recursion or something else,
+we can still add OP_EVAL,... then.
+
+@roconnor:
+> 1. make the script: OP_NOP1 HASH160 <push-20-byte-hash> EQUAL to make
+> it extremely easy to see from the first byte that this is verly likely
+> to be a special transaction (or more accurately if the first byte
+> isn't OP_NOP1 then you immediately know it isn't a special script and
+> can even disregard the token).
+
+I disagree. If people actually do mean HASH160 <hash> EQUAL, let *them*
+add a NOP. Or better to avoid NOP let them use HASH160 <hash>
+EQUALVERIFY 1. Point is, if you don't want code replacement you can
+easily break the pattern. But code replacement will be overwhelmingly
+more common, so it should be as small as possible. Every byte matters.
+
+
+On 1/2/2012 4:59 PM, Gavin Andresen wrote:
+> 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>".
+>
+
+
+