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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <roconnor@theorem.ca>) id 1RgAJE-0003PD-2f
for bitcoin-development@lists.sourceforge.net;
Thu, 29 Dec 2011 07:21:52 +0000
X-ACL-Warn:
Received: from erdos.theorem.ca ([72.2.4.176] helo=theorem.ca)
by sog-mx-1.v43.ch3.sourceforge.com with smtp (Exim 4.76)
id 1RgAJC-0006e1-MF for bitcoin-development@lists.sourceforge.net;
Thu, 29 Dec 2011 07:21:52 +0000
Received: (qmail 2362 invoked by uid 603); 29 Dec 2011 06:55:03 -0000
Received: from localhost (sendmail-bs@127.0.0.1)
by localhost with SMTP; 29 Dec 2011 06:55:03 -0000
Date: Thu, 29 Dec 2011 01:55:03 -0500 (EST)
From: roconnor@theorem.ca
To: bitcoin-development@lists.sourceforge.net
Message-ID: <alpine.LRH.2.00.1112290111310.22327@theorem.ca>
User-Agent: Alpine 2.00 (LRH 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
X-Spam-Score: -1.9 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.3 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain -0.7 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1RgAJC-0006e1-MF
Cc: webmaster@btcguild.com, pool@deepbit.net
Subject: [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 07:21:52 -0000
Gavin asked me to come up with an alternative to OP_EVAL, so here is my
proposal.
OP_CODEHASH Initial Proposal
The idea is to add third "codehash" stack to the scripting engine (or
alternatively a codehash state variable) and have OP_CODESEPARATOR in
addition to its current behaviour push the hash of the remaining code in
the script onto the codehash stack (or alternatively set the codehash
state variable).
Then we add a new OP_CODEHASH operator that pops the codehash stack and
pushes it onto the main stack (or alternatively push the value of the
codehash state variable onto the mainstack which is initialized using the
hash of the sigScript).
The new send-to-script transaction would be:
OP_CODEHASH OP_HASH160 {20-byte-hash-value} OP_EQUAL
Which can be redeemed by
{20-byte-code-hash} signatures OP_CODESEPARATOR code
When run the code will consume all the signatures leaving the
20-byte-code-hash on the stack. When OP_CODEHASH is interpreted as a NOP
it is skipped, then the hash is hashed and compared to the
20-byte-hash-value and a match is required to succeed.
When OP_CODEHASH is interpreted by a new client it pops the codehash stack
and pushes the value onto the main stack, which in this standard
transaction pushes a value identical to the existing {20-byte-code-hash}
on the stack. Then again this hash is hashed and compared to to
{20-byte-code-hash}.
This proposal covers all the desired behaviour from OP_EVAL proposal but
with a less radical change:
(1) you get send-to-script addresses
(2) you cannot redeem with the old client without knowing the hash of the script
OP_CODEHASH has no dynamically generated code that is executed. The
language remains a weak stack based language which is clearly terminating.
The number of operations executed is still bounded by the number of
operations occurring in the script. With the OP_EVAL proposal the script
language becomes essentially Turing complete, with only an artificial
limit on recursion depth preventing arbitrary computation and there is no
way to know what code will run without executing it. With the OP_EVAL
proposal there is no way to statically analyze the script (say to count
the number of uses of OP_CHECKSIG or OP_MULTICHECKSIG or other analysis)
without actually executing the script.
This is just an initial proposal there are clearly some variations that
could be done that would work just as well.
Thanks goes to luke-jr and others for their thoughts on this proposal.
Good night everyone.
--
Russell O'Connor <http://r6.ca/>
``All talk about `theft,''' the general counsel of the American Graphophone
Company wrote, ``is the merest claptrap, for there exists no property in
ideas musical, literary or artistic, except as defined by statute.''
|
