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 smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id AB82DC002B
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 1 Feb 2023 13:05:09 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 6673D81E58
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 1 Feb 2023 13:05:09 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 6673D81E58
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id bphm3WHmXicx
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 1 Feb 2023 13:05:07 +0000 (UTC)
X-Greylist: delayed 18:28:36 by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 6C92A81E30
Received: from smtpout2.mo529.mail-out.ovh.net
(smtpout2.mo529.mail-out.ovh.net [79.137.123.220])
by smtp1.osuosl.org (Postfix) with ESMTPS id 6C92A81E30
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 1 Feb 2023 13:05:07 +0000 (UTC)
Received: from mxplan6.mail.ovh.net (unknown [10.108.16.148])
by mo529.mail-out.ovh.net (Postfix) with ESMTPS id 5F0492149A;
Wed, 1 Feb 2023 12:59:38 +0000 (UTC)
Received: from peersm.com (37.59.142.102) 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; Wed, 1 Feb
2023 13:59:37 +0100
Authentication-Results: garm.ovh; auth=pass
(GARM-102R0045db72702-ae84-4ad4-9653-9fb806f3d46b,
9CED2DE8798109C3417E59800AD64CD0B4D4E981) smtp.auth=aymeric@peersm.com
X-OVh-ClientIp: 92.184.100.26
To: Christopher Allen <ChristopherA@lifewithalacrity.com>, Bitcoin Protocol
Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <CACrqygAMsO1giYuxm=DZUqfeRjEqGM7msmEnZ-AHws3oA2=aqw@mail.gmail.com>
From: Aymeric Vitte <aymeric@peersm.com>
Message-ID: <3e649ce0-f468-f4b4-d774-bc8d5a6ee0f8@peersm.com>
Date: Wed, 1 Feb 2023 13:59:40 +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: <CACrqygAMsO1giYuxm=DZUqfeRjEqGM7msmEnZ-AHws3oA2=aqw@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="------------430033E3BED810211D22EE08"
X-Originating-IP: [37.59.142.102]
X-ClientProxiedBy: DAG5EX1.mxp6.local (172.16.2.41) To DAG6EX2.mxp6.local
(172.16.2.52)
X-Ovh-Tracer-GUID: 00eef9af-86fa-4704-92b9-cd47ebf38218
X-Ovh-Tracer-Id: 7077969766689825690
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedvhedrudefiedggeeiucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepuffvfhfhkffffgggjggtihesrgdtreertdefheenucfhrhhomhepteihmhgvrhhitgcugghithhtvgcuoegrhihmvghrihgtsehpvggvrhhsmhdrtghomheqnecuggftrfgrthhtvghrnhepveduhefgudefhffghfdvleetfffhiefhkeefvddtgedvhfdvffdvvdetuedtgeegnecuffhomhgrihhnpehlihhnuhigfhhouhhnuggrthhiohhnrdhorhhgpdhpvggvrhhsmhdrtghomhdplhhinhhkvgguihhnrdgtohhmpdhgihhthhhusgdrtghomhenucfkphepuddvjedrtddrtddruddpfeejrdehledrudegvddruddtvdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduvdejrddtrddtrddupdhmrghilhhfrhhomhepoegrhihmvghrihgtsehpvggvrhhsmhdrtghomheqpdhnsggprhgtphhtthhopedupdhrtghpthhtohepsghithgtohhinhdquggvvheslhhishhtshdrlhhinhhugihfohhunhgurghtihhonhdrohhrghdpvehhrhhishhtohhphhgvrhetsehlihhfvgifihhthhgrlhgrtghrihhthidrtghomhdpoffvtefjohhsthepmhhohedvledpmhhouggvpehsmhhtphhouhht
X-Mailman-Approved-At: Wed, 01 Feb 2023 14:08:38 +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: Wed, 01 Feb 2023 13:05:09 -0000
--------------430033E3BED810211D22EE08
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Could someone clarify what is the standard for OP_RETURN? As far as I
understand the data is limited to 80B and only one OP_RETURN is allowed
in one transaction, if not the tx is non standard, correct?
Then the debate can be to store in witness indeed
Or you can store in output addresses (with super big size), then you
will never be able to spend the dust and we have a utxo forever
In any case there is a storage workaround, probably others exist, not
sure why people are so opposed to a OP_RETURN bitcoin storage (I thought
the max size was 512B, but apparently I am wrong, 80B is ridiculous,
can't do anything with this, except bypassing this limit by other worse
means)
Storage is the main difference between bitcoin and other systems
(ethereum), without it, repeating myself here again the future of
bitcoin is very limited
PS: I saw the answer of Peter, I am proposing something else for
timestamp proofs
Le 01/02/2023 =E0 01:46, Christopher Allen via bitcoin-dev a =E9crit :
> 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=20
> OP_PUSH my64bytes
> OP_ENDIF
>
> I know that the anti-OP_RETURN folk would say =93neither.=94 But if the=
re
> was no other choice for a particular protocol, such as a timestamp or
> a commitment, which is better? Or is there a safer place to put 64
> bytes that is more uncensorable but also does not clog UTXO space,
> only spent transaction `-txindex` space?
>
> My best guess was that the taproot method is better, but I suspect
> there might be some who disagree. I'd love to hear all sides.
>
> -- Christopher Allen
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--=20
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/Ay=
ms/029125db2583e1cf9c3209769eb2cdd7
A bitcoin NFT system: https://gist.github.com/Ayms/01dbfebf219965054b4a3b=
eed1bfeba7
Move your coins by yourself (browser version): https://peersm.com/wallet
Bitcoin transactions made simple: https://github.com/Ayms/bitcoin-transac=
tions
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.p=
eersm.com
Peersm : http://www.peersm.com
--------------430033E3BED810211D22EE08
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>Could someone clarify what is the standard for OP_RETURN? As far
as I understand the data is limited to 80B and only one OP_RETURN
is allowed in one transaction, if not the tx is non standard,
correct?</p>
<p>Then the debate can be to store in witness indeed<br>
</p>
<p>Or you can store in output addresses (with super big size), then
you will never be able to spend the dust and we have a utxo
forever<br>
</p>
<p>In any case there is a storage workaround, probably others exist,
not sure why people are so opposed to a OP_RETURN bitcoin storage
(I thought the max size was 512B, but apparently I am wrong, 80B
is ridiculous, can't do anything with this, except bypassing this
limit by other worse means)</p>
<p>Storage is the main difference between bitcoin and other systems
(ethereum), without it, repeating myself here again the future of
bitcoin is very limited<br>
</p>
PS: I saw the answer of Peter, I am proposing something else for
timestamp proofs<br>
<br>
<div class="moz-cite-prefix">Le 01/02/2023 à 01:46, Christopher
Allen via bitcoin-dev a écrit :<br>
</div>
<blockquote
cite="mid:CACrqygAMsO1giYuxm=DZUqfeRjEqGM7msmEnZ-AHws3oA2=aqw@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div dir="ltr">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:
<div><br>
OP_FALSE</div>
<div>OP_IF </div>
<div>OP_PUSH my64bytes</div>
<div>OP_ENDIF<br>
<br>
</div>
<div>I know that the anti-OP_RETURN folk would say “neither.”
But if there was no other choice for a particular protocol,
such as a timestamp or a commitment, which is better? Or is
there a safer place to put 64 bytes that is more uncensorable
but also does not clog UTXO space, only spent transaction
`-txindex` space?<br>
</div>
<div><br>
</div>
<div>My best guess was that the taproot method is better, but I
suspect there might be some who disagree. I'd love to hear all
sides.</div>
<div><br>
</div>
<div>-- Christopher Allen</div>
<div><br>
</div>
</div>
<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>
--------------430033E3BED810211D22EE08--
|
