1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <sipa@ulyssis.org>) id 1RgLLN-00080s-4M
for bitcoin-development@lists.sourceforge.net;
Thu, 29 Dec 2011 19:08:49 +0000
X-ACL-Warn:
Received: from rhcavuit02.kulnet.kuleuven.be ([134.58.240.130]
helo=cavuit02.kulnet.kuleuven.be)
by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1RgLLL-0006Fq-Ho for bitcoin-development@lists.sourceforge.net;
Thu, 29 Dec 2011 19:08:49 +0000
X-KULeuven-Envelope-From: sipa@ulyssis.org
X-Spam-Status: not spam, SpamAssassin (not cached, score=-48.798, required 5,
autolearn=disabled, DKIM_ADSP_CUSTOM_MED 0.00,
FREEMAIL_FROM 0.00, KUL_SMTPS -50.00, NML_ADSP_CUSTOM_MED 1.20)
X-KULeuven-Scanned: Found to be clean
X-KULeuven-ID: E71A512808B.A7F91
X-KULeuven-Information: Katholieke Universiteit Leuven
Received: from smtps01.kuleuven.be (smtpshost01.kulnet.kuleuven.be
[134.58.240.74])
by cavuit02.kulnet.kuleuven.be (Postfix) with ESMTP id E71A512808B
for <bitcoin-development@lists.sourceforge.net>;
Thu, 29 Dec 2011 20:08:39 +0100 (CET)
Received: from smtp.ulyssis.org (mail.ulyssis.student.kuleuven.be
[193.190.253.235])
by smtps01.kuleuven.be (Postfix) with ESMTP id B38C931E702
for <bitcoin-development@lists.sourceforge.net>;
Thu, 29 Dec 2011 20:08:39 +0100 (CET)
Received: from wop.ulyssis.org (wop.intern.ulyssis.org [192.168.0.182])
by smtp.ulyssis.org (Postfix) with ESMTP id D837210052
for <bitcoin-development@lists.sourceforge.net>;
Thu, 29 Dec 2011 20:08:39 +0100 (CET)
Received: by wop.ulyssis.org (Postfix, from userid 615)
id D0A6D87C1AB; Thu, 29 Dec 2011 20:08:39 +0100 (CET)
Date: Thu, 29 Dec 2011 20:08:39 +0100
X-Kuleuven: This mail passed the K.U.Leuven mailcluster
From: Pieter Wuille <pieter.wuille@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Message-ID: <20111229190838.GA29609@ulyssis.org>
References: <alpine.LRH.2.00.1112290111310.22327@theorem.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.LRH.2.00.1112290111310.22327@theorem.ca>
X-PGP-Key: http://sipa.ulyssis.org/pubkey.asc
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Spam-Score: 1.2 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(pieter.wuille[at]gmail.com)
0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is
CUSTOM_MED 1.2 NML_ADSP_CUSTOM_MED ADSP custom_med hit,
and not from a mailing list
X-Headers-End: 1RgLLL-0006Fq-Ho
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: Thu, 29 Dec 2011 19:08:49 -0000
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:
* It looks at the two elements most recently (in code position) pushed by a literal,
and not yet consumed by another OP_CHECKEDEVAL. These are S (the serialized script),
and H (its hash). This implies it defines its own literal-only stack, where all
literals push to, and only OP_CHECKEDEVAL pops from. This special stack has the
advantage of allowing static analysis - one does not need to execute any operations
to find out which data will end up on it. Note that "skipped" code (inside the
ignored part of an IF-THEN-ELSE) can still push to the literal stack.
* For the "outer script", it does not have any effect at all, except for:
* 2 elements popped from the literal-only stack
* potentially causing failure
It does not touch the main stack, alt stack or any other part of the execution state
not listed above.
* Failure is caused when either of these conditions hold:
* No two elements remain on the literal-only stack
* The Hash(S) != H
* The inner script execution caused failure
* For the execution of the inner script:
* It is executed in a completely new and independent execution environnement
* It executes the deserialized S
* It inherits the main stack and alt stack (without the serialized script and the hash
themselves) from the outer execution.
This requires OP_CHECKEDEVAL to immediately follow the push of script and hash,
so the code in the pair < <script> OP_CHECKEDEVAL > can be parsed and interpreted as code,
allowing static analysis.
As OP_CHECKEDEVAL has absolutely no effects except for potentially causing failure, it
is very similar to the OP_NOPx it would replace, and guarantees that interpreting
OP_CHECKEDEVAL as OP_NOPx can never cause the script to become invalid if it wasn't
already.
A basic pay-to-script-hash scriptPubKey is very short:
<scriptHash> OP_CHECKEDEVAL
And it is redeemed using:
<script inputs> <script>
Furthermore, the implementation is very similar to what was already done for
OP_EVAL. Modifications:
* EvalScriptInner needs less by-ref arguments, as it cannot modify the parent's state.
* A literal-only stack needs to be maintained.
I believe this combines all advantages:
* Easy spend-to-script-hash (shorter than OP_EVAL)
* Backward compatible (guaranteed by construction, instead of separately enforced like with OP_EVAL)
* Statically analyzable (though it requires deserializing the script data).
* Possibility to introduce a new language inside (not done in this proposal)
Only disadvantages:
* Slightly less flexible than OP_EVAL, as it disallows dynamic interation with serialized scripts.
* Static code analyzers need to deserialize script data.
Credits: gmaxwell for the idea of a literal-only stack
--
Pieter
|
