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
141
142
143
144
145
146
147
148
149
|
Return-Path: <luke.durback@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 3F429D7B
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 10 Dec 2015 01:35:39 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com
[209.85.213.169])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BEC19187
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 10 Dec 2015 01:35:38 +0000 (UTC)
Received: by mail-ig0-f169.google.com with SMTP id su19so3230750igc.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 09 Dec 2015 17:35:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:from:date:message-id:subject:to:content-type;
bh=wSRMEPLFBavFJeB8fcXQknUx2yd/mq3pqbINshMT02Y=;
b=vWoc78ESF0L0OjJR1ZdgTH+L2f7Fmoa5Th1y2FRMj2I6fKtL5vNHjxcINDEV82e1nW
lK34BVuWxtmNdtTX6Inxr5ciA+WIZVgpuVOcFRkg0G340pbzd+0uuaFvU2KWebBS5eFq
yZJtTl12eATU9OebdtEekqJF/KTJfaU4tXZ3cCYbK1QNHVHuQO+l7+t8/eM0bP+tkPAz
NHAyfNn9O4RJo0SRxQET5i3rAKRAWktyESd37JEF+tcgL6a6aLzOTx9I2M1aPUxVgnKb
7+d/jKEunemt+FCkY56BXmw6uO+0SQw4fzxVdMsmTKudy0y0MTdb9UpRJiSwSbdNtXpd
1B9w==
X-Received: by 10.50.7.9 with SMTP id f9mr31409248iga.6.1449711338187; Wed, 09
Dec 2015 17:35:38 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.12.177 with HTTP; Wed, 9 Dec 2015 17:35:17 -0800 (PST)
From: Luke Durback <luke.durback@gmail.com>
Date: Wed, 9 Dec 2015 20:35:17 -0500
Message-ID: <CAEj3M+wYicoACcpG5YUU6vF8vg98XCcJWmgBiyrJj-xHHxrhig@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=089e0118363456f1d805268139d1
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 10 Dec 2015 02:10:23 +0000
Subject: [bitcoin-dev] Standard BIP Draft: Turing Pseudo-Completeness
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Dec 2015 01:35:39 -0000
--089e0118363456f1d805268139d1
Content-Type: text/plain; charset=UTF-8
Hello Bitcoin-Dev,
I hope this isn't out of line, but I joined the mailing list to try to
start a discussion on adding opcodes to make Script Turing Pseudo-Complete
as Wright suggested is possible.
---
In line with Wright's suggestion, I propose adding a return stack alongside
the, already existing, control stack.
The principle opcodes (excluding conditional versions of call and
return_from) needed are
OP_DEFINITION_START FunctionName: The code that follows is the definition
of a new function to be named TransactionSenderAddress.FunctionName. If
this function name is already taken, the transaction is marked invalid.
Within the transaction, the function can be called simply as FunctionName.
OP_DEFINITION_END: This ends a function definition
OP_FUNCTION_NAME FunctionName: Gives the current transaction the name
FunctionName (this is necessary to build recursive functions)
---
OP_CALL Namespace.FunctionName Value TransactionFee: This marks the
transaction as valid. It also pushes the current execution location onto
the return stack, debits the calling transaction by the TransactionFee and
Value, and creates a new transaction specified by Namespace.FunctionName
with both stacks continued from before (this may be dangerous, but I see no
way around it) with the specified value.
OP_RETURN_FROM_CALL_AND_CONTINUE: This pops the top value off the return
stack and continues from the specified location with both stacks in tact.
---
It would also be useful if a transaction can create another transaction
arbitrarily, so to prepare for that, I additionally propose
OP_NAMESPACE: Pushes the current namespace onto the control stack
This, combined with the ability to make new transactions arbitrarily would
allow a function to pay its creator.
I understand that this isn't all that is needed, but I think it's a start.
I hope this proposal has met you all well,
Luke Durback
--089e0118363456f1d805268139d1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hello Bitcoin-Dev,<br></div><div><br></div><div>I hop=
e this isn't out of line, but I joined the mailing list to try to start=
a discussion on adding opcodes to make Script Turing Pseudo-Complete as Wr=
ight suggested is possible.</div><div><br></div><div>---</div><div><br></di=
v><div>In line with Wright's suggestion, I propose adding a return stac=
k alongside the, already existing, control stack.</div><div><br></div><div>=
The principle opcodes (excluding conditional versions of call and return_fr=
om) needed are</div><div><br></div><div>OP_DEFINITION_START FunctionName: =
=C2=A0The code that follows is the definition of a new function to be named=
TransactionSenderAddress.FunctionName.=C2=A0 If this function name is alre=
ady taken, the transaction is marked invalid.=C2=A0 Within the transaction,=
the function can be called simply as FunctionName.</div><div><br></div><di=
v>OP_DEFINITION_END: =C2=A0This ends a function definition</div><div><div><=
br></div><div>OP_FUNCTION_NAME FunctionName: =C2=A0Gives the current transa=
ction the name FunctionName (this is necessary to build recursive functions=
)</div></div><div><br></div><div>---</div><div><br></div><div>OP_CALL Names=
pace.FunctionName Value TransactionFee: =C2=A0This marks the transaction as=
valid.=C2=A0 It also pushes the current execution location onto the return=
stack, debits the calling transaction by the TransactionFee and Value, and=
creates a new transaction specified by Namespace.FunctionName with both st=
acks continued from before (this may be dangerous, but I see no way around =
it) with the specified value.</div><div><br></div><div>OP_RETURN_FROM_CALL_=
AND_CONTINUE: =C2=A0This pops the top value off the return stack and contin=
ues from the specified location with both stacks in tact.</div><div><br></d=
iv><div>---<br></div><div><br></div><div>It would also be useful if a trans=
action can create another transaction arbitrarily, so to prepare for that, =
I additionally propose</div><div><br></div><div>OP_NAMESPACE: =C2=A0Pushes =
the current namespace onto the control stack<br><br>This, combined with the=
ability to make new transactions arbitrarily would allow a function to pay=
its creator.</div><div><br></div><div><br></div><div><br></div><div>I unde=
rstand that this isn't all that is needed, but I think it's a start=
.=C2=A0 I hope this proposal has met you all well,</div><div><br></div><div=
>Luke Durback</div></div>
--089e0118363456f1d805268139d1--
|
