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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id A9E66DB8
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 24 May 2019 04:15:55 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch
[185.70.40.133])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C33B9F4
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 24 May 2019 04:15:54 +0000 (UTC)
Date: Fri, 24 May 2019 04:15:45 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1558671352;
bh=/wUZNNlXT55bYIu9iwyMDpA+6RKEd9P7SB+eqBwOkDE=;
h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID:
From;
b=j5h0uF82IOUaNdC40mIQSrZ5iTpla0UAv/0tqLIFJucchQKDjCyCGja01OTQLkhdB
xHFQYROX1D7Q+ZeLRJ/lE6uarmYfryg8kMp6C/bKBRbJSacQarrRgnyjJSxWbWobPN
g0LGrw/LTMqjehy0fvqe4+ad7D8YdDG+xTYGwkQc=
To: Russell O'Connor <roconnor@blockstream.io>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <CCdF2y99R_xiyrtQ3F80GDSpQVWJztgS71HaHXEHq1cZmj0om0Ge7yMEtx_QY4MMOD6qHT1YE3cn-3o-wVWWS3KatMQE8W-GJnolna_prsI=@protonmail.com>
In-Reply-To: <CAMZUoK=0YhqxguphmaKsMGZCy_NYVE_i53qGBfPVES=GAYTy1g@mail.gmail.com>
References: <CAMZUoK=0YhqxguphmaKsMGZCy_NYVE_i53qGBfPVES=GAYTy1g@mail.gmail.com>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL,
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: Fri, 24 May 2019 14:39:19 +0000
Subject: Re: [bitcoin-dev] An alternative: OP_CAT & OP_CHECKSIGFROMSTACK
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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: Fri, 24 May 2019 04:15:55 -0000
> For better or for worse, without an OP_PUBKEYTWEEK operation available, t=
he more interesting recursive-covenants remain largely out of reach, with t=
he exception of a recursive covenant that is only able to send back to its =
own address, possibly abusing its own TXO value as a state variable.
After some thinking, I may have devised a way to achieve the more interesti=
ng Turing-complete system (where each "loop through" requires paying a fee =
to miners, akin to Ethereum Gas, and thus a good way to build new footguns)=
even without `OP_PUBKEYTWEAK`.
I observe the following:
1. `OP_CHECKSIGFROMSTACK` can introspect into the transaction *doing the s=
pend* by giving the transaction (minus witness) as part of the witness (i.e=
. quining).
2. The above can be leveraged to introspect into the transaction *being sp=
ent* by giving that transaction *being spent* (minus witness) as part of th=
e witness stack.
This is because the transaction *doing the spend* commits to the transa=
ction *being spent* by referring to its txid.
We can concatenate the bits of the previous transaction and confirm tha=
t it is indeed the transaction *being spent* by hashing and comparing that =
to the txid in the input of the transaction *doing the spend*.
3. The transaction *being spent* can contain an `OP_RETURN` output that co=
ntains the previous state (or a commitment to the previous state if it is t=
oo large to fit in an `OP_RETURN`, again requiring that the previous state =
be given as part of the witness).
Since it can be introspected, a script can acquire a "previous state" d=
ata.
4. The transaction *doing the spend* can also contain an `OP_RETURN` with =
the next state (or commitment to next state).
5. The rest of the script can then determine if the transition from "previ=
ous state" to "next state" is valid.
6. The script can impose that the same script is paid to by introspecting =
the transaction *being spent* to get at a commitment to itself.
The above seems enough to create a potentially unbound loop, bound only by =
the amount of money you are willing to spend on fees operating that loop.
The "state" would be the memory of your virtual machine, and the SCRIPT val=
idates the execution of one iteration of the interpreter loop, and that wou=
ld be enough to create a Turing-complete system within Bitcoin.
With MAST, you can compress branches not taken, reducing the number of oper=
ations you have to expose at each iteration.
I admit *creating* this by hand will probably be very difficult, but that s=
hould be doable with an army of lower-level cognition agents.
(disclaimer: I am not an AI with an army of lower-level cognition agents an=
d I can completely and totally pass the Turing test)
Regards,
ZmnSCPxj
|
