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
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
|
Return-Path: <aymeric@peersm.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 504EDC002B
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 2 Feb 2023 11:45:49 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 1E0DF41B6D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 2 Feb 2023 11:45:49 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 1E0DF41B6D
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001,
RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001,
SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id DMKEQhYUP0RC
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 2 Feb 2023 11:45:46 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 9649741B61
Received: from 8.mo548.mail-out.ovh.net (8.mo548.mail-out.ovh.net
[46.105.45.231])
by smtp4.osuosl.org (Postfix) with ESMTPS id 9649741B61
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 2 Feb 2023 11:45:46 +0000 (UTC)
Received: from mxplan6.mail.ovh.net (unknown [10.109.156.48])
by mo548.mail-out.ovh.net (Postfix) with ESMTPS id 0F5FE20B26;
Thu, 2 Feb 2023 11:45:43 +0000 (UTC)
Received: from peersm.com (37.59.142.101) by DAG6EX2.mxp6.local (172.16.2.52)
with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.17; Thu, 2 Feb
2023 12:45:43 +0100
Authentication-Results: garm.ovh; auth=pass
(GARM-101G004d528f3d9-448b-490a-b6f1-ea707c13d5ad,
6AA1D679F834A14CBEAA49266E816969C7C1CEBF) smtp.auth=aymeric@peersm.com
X-OVh-ClientIp: 92.184.100.16
To: Peter Todd <pete@petertodd.org>, Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>, Andrew Poelstra
<apoelstra@wpsoftware.net>
References: <CACrqygAMsO1giYuxm=DZUqfeRjEqGM7msmEnZ-AHws3oA2=aqw@mail.gmail.com>
<764E460B-C0C6-47B8-A97E-F7CBC81FD645@petertodd.org> <Y9pxAdm3kO1rr2kU@camus>
<Y9uc72RSs6LQojG4@petertodd.org>
From: Aymeric Vitte <aymeric@peersm.com>
Message-ID: <16446c77-c9de-7b11-8e66-7f8e20421cba@peersm.com>
Date: Thu, 2 Feb 2023 12:45:42 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <Y9uc72RSs6LQojG4@petertodd.org>
Content-Type: multipart/alternative;
boundary="------------741F1923621C33C05D5E6C54"
X-Originating-IP: [37.59.142.101]
X-ClientProxiedBy: DAG1EX2.mxp6.local (172.16.2.2) To DAG6EX2.mxp6.local
(172.16.2.52)
X-Ovh-Tracer-GUID: e7206ec9-679c-4138-9595-6767acc0998c
X-Ovh-Tracer-Id: 11702322158756914141
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedvhedrudefkedgfedtucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepuffvfhfhkffffgggjggtihesrgdtreertdefheenucfhrhhomhepteihmhgvrhhitgcugghithhtvgcuoegrhihmvghrihgtsehpvggvrhhsmhdrtghomheqnecuggftrfgrthhtvghrnhepveduhefgudefhffghfdvleetfffhiefhkeefvddtgedvhfdvffdvvdetuedtgeegnecuffhomhgrihhnpehlihhnuhigfhhouhhnuggrthhiohhnrdhorhhgpdhpvggvrhhsmhdrtghomhdplhhinhhkvgguihhnrdgtohhmpdhgihhthhhusgdrtghomhenucfkphepuddvjedrtddrtddruddpfeejrdehledrudegvddruddtudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduvdejrddtrddtrddupdhmrghilhhfrhhomhepoegrhihmvghrihgtsehpvggvrhhsmhdrtghomheqpdhnsggprhgtphhtthhopedupdhrtghpthhtoheprghpohgvlhhsthhrrgesfihpshhofhhtfigrrhgvrdhnvghtpdgsihhttghoihhnqdguvghvsehlihhsthhsrdhlihhnuhigfhhouhhnuggrthhiohhnrdhorhhgpdhpvghtvgesphgvthgvrhhtohguugdrohhrghdpoffvtefjohhsthepmhhoheegkedpmhhouggvpehsmhhtphhouhht
X-Mailman-Approved-At: Thu, 02 Feb 2023 12:03:27 +0000
Subject: Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE
OP_IF OP_PUSH
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: Thu, 02 Feb 2023 11:45:49 -0000
--------------741F1923621C33C05D5E6C54
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
As far as I can read nobody replied to the initial question: what is
considered as good/best practice to store in Bitcoin?
Reiterating my question: what are the current rules for OP_RETURN, max
size and number of OP_RETURN per tx
Le 02/02/2023 à 12:22, Peter Todd via bitcoin-dev a écrit :
> On Wed, Feb 01, 2023 at 02:02:41PM +0000, Andrew Poelstra wrote:
>> On Tue, Jan 31, 2023 at 09:07:16PM -0500, Peter Todd via bitcoin-dev wrote:
>>>
>>> On January 31, 2023 7:46:32 PM EST, Christopher Allen via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>> All other things being equal, which is better if you need to place a
>>>> 64-bytes into the Bitcoin blockchain? A traditional OP_RETURN or a spent
>>>> taproot transaction such as:
>>>>
>>>> OP_FALSE
>>>> OP_IF
>>>> OP_PUSH my64bytes
>>>> OP_ENDIF
>>> What's wrong with OpPush <data> OpDrop?
>>>
>> This is a technical nit, but the reason is that <data> is limited to 520
>> bytes (and I believe, 80 bytes by standardness in Taproot), so if you
>> are pushing a ton of data and need multiple pushes, it's more efficient
>> to use FALSE IF ... ENDIF since you avoid the repeated DROPs.
> Yes, for more than 520 bytes you need to wrap the push in an IF/ENDIF so it's
> not executed. But in this example we're just talking about 64 bytes, so that
> limit isn't relevant and OpPush <data> OpDrop should be sufficient.
>
> Specifically for more than 520 bytes you run into the the
> MAX_SCRIPT_ELEMENT_SIZE check in script/interpreter.cpp, which applies to all
> scripts regardless of standardness at script execution:
>
> //
> // Read instruction
> //
> if (!script.GetOp(pc, opcode, vchPushValue))
> return set_error(serror, SCRIPT_ERR_BAD_OPCODE);
> if (vchPushValue.size() > MAX_SCRIPT_ELEMENT_SIZE)
> return set_error(serror, SCRIPT_ERR_PUSH_SIZE);
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Sophia-Antipolis, France
CV: https://www.peersm.com/CVAV.pdf
LinkedIn: https://fr.linkedin.com/in/aymeric-vitte-05855b26
GitHub : https://www.github.com/Ayms
A Universal Coin Swap system based on Bitcoin: https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transactions
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.peersm.com
Peersm : http://www.peersm.com
--------------741F1923621C33C05D5E6C54
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>As far as I can read nobody replied to the initial question: what
is considered as good/best practice to store in Bitcoin?</p>
<p>Reiterating my question: what are the current rules for
OP_RETURN, max size and number of OP_RETURN per tx<br>
</p>
<br>
<div class="moz-cite-prefix">Le 02/02/2023 à 12:22, Peter Todd via
bitcoin-dev a écrit :<br>
</div>
<blockquote cite="mid:Y9uc72RSs6LQojG4@petertodd.org" type="cite">
<pre wrap="">On Wed, Feb 01, 2023 at 02:02:41PM +0000, Andrew Poelstra wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Tue, Jan 31, 2023 at 09:07:16PM -0500, Peter Todd via bitcoin-dev wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
On January 31, 2023 7:46:32 PM EST, Christopher Allen via bitcoin-dev <a class="moz-txt-link-rfc2396E" href="mailto:bitcoin-dev@lists.linuxfoundation.org"><bitcoin-dev@lists.linuxfoundation.org></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">All other things being equal, which is better if you need to place a
64-bytes into the Bitcoin blockchain? A traditional OP_RETURN or a spent
taproot transaction such as:
OP_FALSE
OP_IF
OP_PUSH my64bytes
OP_ENDIF
</pre>
</blockquote>
<pre wrap="">
What's wrong with OpPush <data> OpDrop?
</pre>
</blockquote>
<pre wrap="">
This is a technical nit, but the reason is that <data> is limited to 520
bytes (and I believe, 80 bytes by standardness in Taproot), so if you
are pushing a ton of data and need multiple pushes, it's more efficient
to use FALSE IF ... ENDIF since you avoid the repeated DROPs.
</pre>
</blockquote>
<pre wrap="">
Yes, for more than 520 bytes you need to wrap the push in an IF/ENDIF so it's
not executed. But in this example we're just talking about 64 bytes, so that
limit isn't relevant and OpPush <data> OpDrop should be sufficient.
Specifically for more than 520 bytes you run into the the
MAX_SCRIPT_ELEMENT_SIZE check in script/interpreter.cpp, which applies to all
scripts regardless of standardness at script execution:
//
// Read instruction
//
if (!script.GetOp(pc, opcode, vchPushValue))
return set_error(serror, SCRIPT_ERR_BAD_OPCODE);
if (vchPushValue.size() > MAX_SCRIPT_ELEMENT_SIZE)
return set_error(serror, SCRIPT_ERR_PUSH_SIZE);
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
bitcoin-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>
<a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Sophia-Antipolis, France
CV: <a class="moz-txt-link-freetext" href="https://www.peersm.com/CVAV.pdf">https://www.peersm.com/CVAV.pdf</a>
LinkedIn: <a class="moz-txt-link-freetext" href="https://fr.linkedin.com/in/aymeric-vitte-05855b26">https://fr.linkedin.com/in/aymeric-vitte-05855b26</a>
GitHub : <a class="moz-txt-link-freetext" href="https://www.github.com/Ayms">https://www.github.com/Ayms</a>
A Universal Coin Swap system based on Bitcoin: <a class="moz-txt-link-freetext" href="https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7">https://gist.github.com/Ayms/029125db2583e1cf9c3209769eb2cdd7</a>
A bitcoin NFT system: <a class="moz-txt-link-freetext" href="https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7">https://gist.github.com/Ayms/01dbfebf219965054b4a3beed1bfeba7</a>
Move your coins by yourself (browser version): <a class="moz-txt-link-freetext" href="https://peersm.com/wallet">https://peersm.com/wallet</a>
Bitcoin transactions made simple: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/bitcoin-transactions">https://github.com/Ayms/bitcoin-transactions</a>
torrent-live: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/torrent-live">https://github.com/Ayms/torrent-live</a>
node-Tor : <a class="moz-txt-link-freetext" href="https://www.github.com/Ayms/node-Tor">https://www.github.com/Ayms/node-Tor</a>
Anti-spies and private torrents, dynamic blocklist: <a class="moz-txt-link-freetext" href="http://torrent-live.peersm.com">http://torrent-live.peersm.com</a>
Peersm : <a class="moz-txt-link-freetext" href="http://www.peersm.com">http://www.peersm.com</a></pre>
</body>
</html>
--------------741F1923621C33C05D5E6C54--
|
