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
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
|
Delivery-date: Wed, 11 Dec 2024 22:15:56 -0800
Received: from mail-qv1-f55.google.com ([209.85.219.55])
by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
(Exim 4.94.2)
(envelope-from <bitcoindev+bncBDVJRHEUX4BRBE775G5AMGQEE4WE5TY@googlegroups.com>)
id 1tLcUN-0002oK-Vm
for bitcoindev@gnusha.org; Wed, 11 Dec 2024 22:15:56 -0800
Received: by mail-qv1-f55.google.com with SMTP id 6a1803df08f44-6d8e815eb39sf4780986d6.2
for <bitcoindev@gnusha.org>; Wed, 11 Dec 2024 22:15:55 -0800 (PST)
ARC-Seal: i=2; a=rsa-sha256; t=1733984150; cv=pass;
d=google.com; s=arc-20240605;
b=C6Sj3WlJhpjWxdurquwnRXbou5nEjZGJ+3c6OACpKtyRNaZtZk762350zGcYDXJch2
iF/fz1eh9bHzUJ3M1Tlq2olHGvibz+zs1ZGMwjf2g8/uzRCjo5MDQuyJ0apvb86NtsUm
4rBaj0+bbVKNzCTdo0OHkHlilhwM0LJT7DXLysNzgTmPIT7wkUwVy+CJ9DOOhFlQNgie
aLfroXF9MR5qYu6lqRKhEi5mdAc/2tbOIxN99LLcRJvyqNV6+uK8lHJGW7htyPr+UFFj
dwbmisf9PgjxdxvGnRq26ikxm/pk3MAi0FXmhGAsRCJG/zqp2tmfbEhp6FhP/00AHv8c
8EXQ==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:in-reply-to:content-disposition
:mime-version:references:message-id:subject:cc:to:from:date:sender
:dkim-signature;
bh=iM1TEhHXhHDjnM0SZ1wavSGFzwErB5lnlZV+YnJBxgI=;
fh=AzCHzIHQbiTDdEfqwDUIN5dWhUkUq7176fZgmqFhyi0=;
b=AX0XDy69QltLusVBiAvmWczVrHxAOYsf2Jx/UqWKhVzfiiRWsAPprXDDno6ZcmSv4+
OFQNAuNE2ARKOcfjZvgdhmf/6q9eYEHk4JG3KrEMqD0MbEMc0wjSvBcaiLTa39QHi/U4
bvd2z2l9S/61Ggg5UoOWG6HlkZ+gKWfGx9i2PdWdMGhj3h/JplfTarLb2/0w0QtqDFKV
BCr5E4mTW0LivHMwMKexTdav3L4V1Wkm2mw+pDWaLXDWc+qzS13CPU2OC0lfWhtH1PoX
V73+J4rMGtTmVQ25Y/hE87qlSWogp37y97qvgk16ISPp96+zVz5ioNaxpam+L0vlrt3s
0yzA==;
darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
dkim=pass header.i=@reardencode.com header.s=mail header.b=JIi738KX;
spf=pass (google.com: domain of freedom@reardencode.com designates 2607:f2f8:ad40:ea11::1 as permitted sender) smtp.mailfrom=freedom@reardencode.com;
dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=reardencode.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlegroups.com; s=20230601; t=1733984150; x=1734588950; darn=gnusha.org;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-authentication-results
:x-original-sender:in-reply-to:content-disposition:mime-version
:references:message-id:subject:cc:to:from:date:sender:from:to:cc
:subject:date:message-id:reply-to;
bh=iM1TEhHXhHDjnM0SZ1wavSGFzwErB5lnlZV+YnJBxgI=;
b=RcqYzuWh8UbiZAgi/zaczLVjS7JndrSymyDWrRQqgRaYIeqxctUzRo1W7gYkk2wpw2
VA/kc5Sc3blLTwSCxxY+X9V5U+qwZuhFq76iRi4wtF+xPWy+guWBXFPenUD7jD+zaRgW
ONVyvSSY61HcTJncBC+M0J4ZPHAl58UEW9ys8OlBygXcNmBVjK3tgUXEvD6PVEx0iRCa
W5sn7JA6Z8qDOptCtWgXe72Pn3ZktJuQZD2ufPuHv8DQRhiidR+K5rGtscr8fQBQsazz
hnZHahd977SSpDenebrSw8wK1QPvZe2xxiCTZZp/LgcOOt285xkuXEWW6FM/psmHqxrR
BGMA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1733984150; x=1734588950;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-authentication-results
:x-original-sender:in-reply-to:content-disposition:mime-version
:references:message-id:subject:cc:to:from:date:x-beenthere
:x-gm-message-state:sender:from:to:cc:subject:date:message-id
:reply-to;
bh=iM1TEhHXhHDjnM0SZ1wavSGFzwErB5lnlZV+YnJBxgI=;
b=PzxbSXK6jkAQBvSGnOR8Vb8yWAdXrbRp+x6KjLDHX7xVws2Mt6PQs8Mpna1DQnC+Se
XVoEs3sYeneU6uL+riJ36liROIeBgbBxAU2/0HXdDjoIAZR2L+JpeFZtlhkpdLywXpQT
g357SNhdxxSpy8uz/ytbyWqBNQ3rm5EhaldogfvUhkNu10Ytj2ZgrEhJz5rgecp38AhQ
lgB+29eIvbc15TCessenzHjvtRDsZcuADCAnLP4AsqXkcQhuoCH+bMwpsb+T3WQoqo6B
mrZ1hPXNqfmcTc8gucfdKQnwHVVoN+MsbfU3AieXwWLG3UsaXZgwtrV3iXvaXV404Bml
K0JA==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCWw8fSYzapD/10Y95EjJSsklk9pWXbXmAL0lQ5cHXJJn75AlejqOGOE6x8jfaKGomploNVd1VjMhSxH@gnusha.org
X-Gm-Message-State: AOJu0YwwQIxqeHb9ixK9S+ku+gOKifpQyc48t2qQoxhffCTxzIeSWNMN
BK1niJkpVhh/HtPZfQOsM30sU7izMkQLRLce/ePIrDx8T1+eD9o4
X-Google-Smtp-Source: AGHT+IHRlVv6znkrSVOIWTdfZ8qroeZQ65CnnvqcSdNk3wkk7dc9+eWsK/65JyUHhjXj5XGPak4xCg==
X-Received: by 2002:ad4:5baa:0:b0:6d8:a5a6:f489 with SMTP id 6a1803df08f44-6dae392ca3bmr32447766d6.26.1733984149646;
Wed, 11 Dec 2024 22:15:49 -0800 (PST)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a0c:d6c7:0:b0:6d8:ee03:1a2d with SMTP id 6a1803df08f44-6dae3819f18ls673626d6.1.-pod-prod-01-us;
Wed, 11 Dec 2024 22:15:47 -0800 (PST)
X-Forwarded-Encrypted: i=2; AJvYcCVN2nd33NEce98lVyTp7vkiihW90RWtJpWaED34knRzI1tAabKTaggbb3u7fO4tuRS9LUvTSHRvnr/3@googlegroups.com
X-Received: by 2002:ad4:5ae9:0:b0:6d4:3c10:5065 with SMTP id 6a1803df08f44-6dae395ecdfmr31892116d6.32.1733984147551;
Wed, 11 Dec 2024 22:15:47 -0800 (PST)
Received: by 2002:ae9:f406:0:b0:7b6:d314:a4e5 with SMTP id af79cd13be357-7b6f31a3415ms85a;
Wed, 11 Dec 2024 21:50:23 -0800 (PST)
X-Forwarded-Encrypted: i=2; AJvYcCVUeuuU1oC972SpP4uVsDML9q6wbJzXycl8PyFpoZ30STQg8xpdvli7YKdeF+ljNPf425DFI/R/eyWy@googlegroups.com
X-Received: by 2002:a05:6122:1d51:b0:518:965c:34a with SMTP id 71dfb90a1353d-518b5cc7723mr2364117e0c.2.1733982623301;
Wed, 11 Dec 2024 21:50:23 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1733982623; cv=none;
d=google.com; s=arc-20240605;
b=iemr6KzjQpmBZ8KmFkpPOOUtZZrpm/x/hevOz4YE/C77k6Hh6QRIzcFYGcPtTTZx8f
05MJpmfeQ4+8CLH5w1ouaqzVf22bvly8ItUTQWyq+yH1oRCQRDF45JZzoT4NRhaqFdhA
wGYDmqQTtfYM4mtajPaE5lFkKYEv0S+sGMd/GCPIoEsy4LmJ7eQLKERFL6bmIq2a3R7K
GMZpIeY8xZGTQEkWgm0oFmIFV0Iaoyz8RjjNxQcJUBTBgKmRBUdwTF4cYCpimEtQ9cv1
V7/9xDbIp+Ym3Usl4KQHRJOIOU/utgRN3X3eGnbXhVoMPLGMRb1Tzt6CYYzYgyoz+8Ed
ebfg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605;
h=in-reply-to:content-disposition:mime-version:references:message-id
:subject:cc:to:from:dkim-signature:date;
bh=fuFRqH9UFLnkpLejLWc7aWmuKqB/V3HbiXcqtQkX8XA=;
fh=roiYaGK86U74SKQPFbJNbEX2eYYfcyTsLRTiAns/QbM=;
b=bwGNFCmu5ykod9tKDHqbyYaE2RR0vkP7sZxwBBeMPEA7X02ivsMEFgCZRVIdvazxEM
TWxG3u3bvsheqstqPLYOk0vAZlst6woAc2NNXx8ZFcd9EekqcFiKmgfRm7pq8Kcn0I8i
7hXEukamh3HcTuSeqksh3PaRuKgk3tGJk0G+TZmaDAMSynhZ8MQ4tuXjlZTN7iGYuy1n
2GHGsbl80o0/nwKpRZpwseE3u6wyJyxVWf8eVeafiFtbpp+avNiKWOrO0J7k7avKsfYe
SKMkzyiQDCUy4PJrOR6h5ImrdsU+hxd15Arwpup8LGj0WgtWnn0s1KDO8U7wfCxmVApt
4qlg==;
dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
dkim=pass header.i=@reardencode.com header.s=mail header.b=JIi738KX;
spf=pass (google.com: domain of freedom@reardencode.com designates 2607:f2f8:ad40:ea11::1 as permitted sender) smtp.mailfrom=freedom@reardencode.com;
dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=reardencode.com
Received: from mail.reardencode.com ([2607:f2f8:ad40:ea11::1])
by gmr-mx.google.com with ESMTPS id 71dfb90a1353d-5161637e295si529166e0c.5.2024.12.11.21.50.22
for <bitcoindev@googlegroups.com>
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Wed, 11 Dec 2024 21:50:22 -0800 (PST)
Received-SPF: pass (google.com: domain of freedom@reardencode.com designates 2607:f2f8:ad40:ea11::1 as permitted sender) client-ip=2607:f2f8:ad40:ea11::1;
Date: Wed, 11 Dec 2024 21:49:48 -0800
From: Brandon Black <freedom@reardencode.com>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Andrew Poelstra <apoelstra@wpsoftware.net>,
Weikeng Chen <weikeng.chen@l2iterative.com>,
Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Difficulty in emulating "weaker" OP_SUCCESS and why
it should be a real opcode
Message-ID: <Z1p5fA6-ZcMtPLOq@console>
References: <ebd77d82-96ab-4530-909a-d085378b9868n@googlegroups.com>
<Z1dAQ8pSIqn8XA56@camus>
<Z1dp0Jtbrkcf7Roi@console>
<87ttbccrql.fsf@rustcorp.com.au>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline
In-Reply-To: <87ttbccrql.fsf@rustcorp.com.au>
X-Operating-System: Linux 6.6.36 x86_64
X-Original-Sender: freedom@reardencode.com
X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass
header.i=@reardencode.com header.s=mail header.b=JIi738KX; spf=pass
(google.com: domain of freedom@reardencode.com designates 2607:f2f8:ad40:ea11::1
as permitted sender) smtp.mailfrom=freedom@reardencode.com; dmarc=pass
(p=NONE sp=NONE dis=NONE) header.from=reardencode.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
<https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.8 (/)
On 2024-12-10 (Tue) at 10:51:38 +1030, Rusty Russell wrote:
> Brandon Black <freedom@reardencode.com> writes:
> > It occurred to me today when thinking about Weikeng's post that we can
> > slightly weaken the existing OP_SUCCESS behavior while retaining
> > essentially all of its benefits in practice without introducing
> > OP_SEGMENT by leveraging OP_CODESEPARATOR. Redefine OP_SUCCESS with a
> > soft fork from "make the script unconditionally valid" to "make the
> > script segment unconditionally valid", and define a script segment as
> > "each lexicographic section of the script containing no
> > OP_CODESEPARATOR".
> >
> > The script interpreter can perform SUCCESS checking as it currently does
> > until it encounters an OP_CODESEPARATOR. Each OP_CODESEPARATOR gets a
> > "SUCCESS" flag defaulted to false and SUCCESS checking now sets that
> > flag to true on the most recently encountered OP_CODESEPARATOR.
> >
> > During script execution, whenever an OP_CODESEPARATOR is popped (not
> > executed) its "SUCCESS" flag value is copied to the interpreter state.
> > After this state setting conditional, if the interpreter "SUCCESS" flag
> > is true, and fExec is true, the script immediately succeeds.
>
> Beware success inside branches? This is why I preferred to segment the
> script and scan for OP_SUCCESS and evaluate each part in order (if you
> have part of an if statement inside one segment, you fail as expected).
> This is actually not that different inside Bitcoin's script.cpp.
I believe my description of CODESEPARATOR segments has a predictable but
different handling of SUCCESS with conditionals. As long as interpreter
state change are handled in order:
* update success mode if opcode is CODESEPARATOR
* if execution enabled by flow control and success mode is true, succeed
* execute operation if enabled or operation is flow control
That said, I've just reread [BIP342] and realized that the designers of
tapscript had greater things in mind for SUCCESS than I had remembered
(e.g. the existence of an SUCCESS can be used to change the behavior of
other opcodes or even stack limits) which would not work at all well
with segmented SUCCESS.
Some of these be possible with segmented execution, but not all.
Based on this, I'm now in favor of Weikeng's idea for a runtime success
operator possibly akin to the original RETURN. If it were equivalent to
the original RETURN, it would be a useful alternative to VERIFY in
certain cases.
> (Also: CODESEPARATOR is cursed, so I chose a different name :)
Isn't tapscript CODESEPARATOR uncursed? :)
Aside: Because SUCCESS allows for changing resource limits and more,
restored script can mostly be implemented in tapscript 0xc0. If any of
the new opcodes are present, 1NEGATE is redefined to TX (or something),
numbers are bigwholes, limits are varops, etc. Gets a little weird if
someone wants to write a restored script without any of the new ops, so
maybe you also provide an RESTORE that does nothing other than trigger
the mode change.
All the best,
--Brandon
[BIP342]: https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/Z1p5fA6-ZcMtPLOq%40console.
|
