summaryrefslogtreecommitdiff
path: root/12/4863e7249d4e82cf658a4a4d811dc5d24afbae
blob: 751b615e1cbc46d194d74a6a953210caa0dd6a54 (plain)
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
Return-Path: <vjudeu@gazeta.pl>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 2E760C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 11 May 2022 10:57:10 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 0DB29610B9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 11 May 2022 10:57:10 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
 dkim=pass (1024-bit key) header.d=gazeta.pl
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id qG7YtE2TqrUx
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 11 May 2022 10:57:08 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from smtpo105.poczta.onet.pl (smtpo105.poczta.onet.pl
 [213.180.149.158])
 by smtp3.osuosl.org (Postfix) with ESMTPS id C09D961079
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 11 May 2022 10:57:08 +0000 (UTC)
Received: from pmq1v.m5r2.onet (pmq1v.m5r2.onet [10.174.32.67])
 by smtp.poczta.onet.pl (Onet) with ESMTP id 4KysL53qxSzgcN;
 Wed, 11 May 2022 12:57:01 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013;
 t=1652266621; bh=5Za62nsdX/BUJy3N/DVtQHPO7SQH0kcpgdbt1WoOVYk=;
 h=From:Cc:To:In-Reply-To:Date:Subject:From;
 b=GzVGtLqbjI0ZIXdTrAyAhiN2nCAzxC95kPAWUJbg+x5po9bdLV31yMkcrzaLB+tgm
 GmPLlHOCzrTMEqlDNk0infDgqYWT/E6HQ/M/LWpRDYS+88Yn7gX3ysMkqc/hAMuc0k
 WM3DWLF35Xgdt6jEWyAoDnHBdQl7rBnzjFIFfSkA=
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Received: from [82.177.167.2] by pmq1v.m5r2.onet via HTTP id ;
 Wed, 11 May 2022 12:57:01 +0200
From: vjudeu@gazeta.pl
X-Priority: 3
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,Nadav Ivgi <nadav@shesek.info>
In-Reply-To: <6pDae6X_tAfMTldPPsad5CSHPF98NVbTf06JxRCs7RqJGyrOqLALsDHHa_3C5DbbfpAVnzLMWCn-7e0FwQO-TOk4XxWYIiaYomuA9NJjkEQ=@protonmail.com>
Date: Wed, 11 May 2022 12:57:01 +0200
Message-Id: <161946014-482cdec305e2bd7a2c3fc4774c70239d@pmq1v.m5r2.onet>
X-Mailer: onet.poczta
X-Onet-PMQ: <vjudeu@gazeta.pl>;82.177.167.2;PL;3
X-Mailman-Approved-At: Wed, 11 May 2022 11:13:03 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Speedy covenants (OP_CAT2)
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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: Wed, 11 May 2022 10:57:10 -0000

> Looks like `OP_CAT` is not getting enabled until after we are reasonably =
sure that recursive covenants are not really unsafe.

Maybe we should use OP_SUBSTR instead of OP_CAT. Or even better: OP_SPLIT. =
Then, we could have OP_SPLIT <n> <pos1> <pos2> ... <posN> that would split =
a string N times (so there will be N+1 pieces). Or we could have just OP_SP=
LIT <pos> to split one string into two. Or maybe OP_2SPLIT and OP_3SPLIT, j=
ust to split into two or three pieces (as we have OP_2DUP and OP_3DUP). I t=
hink OP_SUBSTR or OP_SPLIT is better than OP_CAT, because then things alway=
s get smaller and we can be always sure that we will have one byte as the s=
mallest unit in our Script.

On 2022-05-08 04:20:19 user ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists.lin=
uxfoundation.org> wrote:
> Good morning shesek,

> On Sat, May 7, 2022 at 5:08 PM ZmnSCPxj via bitcoin-dev <bitcoin-dev@list=
s.linuxfoundation.org> wrote:
> > * Even ***with*** `OP_CAT`, the following will enable non-recursive cov=
enants without enabling recursive covenants:
> >  * `OP_CTV`, ...
> > * With `OP_CAT`, the following would enable recursive covenants:
> >  * `OP_CHECKSIGFROMSTACK`, ...
>
> Why does CTV+CAT not enable recursive covenants while CSFS+CAT does?
>
> CTV+CAT lets you similarly assert against the outputs and verify that the=
y match some dynamically constructed script.
>
> Is it because CTV does not let you have a verified copy of the input's pr=
evout scriptPubKey on the stack [0], while with OP_CSFS you can because the=
 signature hash covers it?
>
> But you don't actually need this for recursion. Instead of having the use=
r supply the script in the witness stack and verifying it against the input=
 to obtain the quine, the script can simply contain a copy of itself as an =
initial push (minus this push). You can then reconstruct the full script qu=
ine using OP_CAT, as a PUSH(<script>) followed by the literal <script>.

    <OP_PUSH_length-of-script> OP_SWAP OP_DUP OP_CAT OP_CAT <rest of script=
...>

Ha, yes, looks like you are correct here.

`OP_CAT` makes *all* covenant opcodes recursive, because you can always qui=
ne using `OP_CAT`.

By itself it does not make recursive covenants, but with probably any opcod=
e it would.

Looks like `OP_CAT` is not getting enabled until after we are reasonably su=
re that recursive covenants are not really unsafe.

Regards,
ZmnSCPxj
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev