diff options
author | Stefan Thomas <moon@justmoon.de> | 2012-01-02 18:10:25 +0100 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2012-01-02 17:10:41 +0000 |
commit | 09a14303d748dce2e3f196df589a589d1bc9e1a6 (patch) | |
tree | d8f5d6eb4dbe3a6585f45d994f6a3191c6b5fc0d | |
parent | 77c1ad7f21ecdc349cad5b97c88e0dac466f9607 (diff) | |
download | pi-bitcoindev-09a14303d748dce2e3f196df589a589d1bc9e1a6.tar.gz pi-bitcoindev-09a14303d748dce2e3f196df589a589d1bc9e1a6.zip |
Re: [Bitcoin-development] Alternative to OP_EVAL
-rw-r--r-- | 10/9a819be03c0c5585300d85eecaf3db0f1e6b3b | 123 |
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>". +> + + + |