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
|
Return-Path: <murch@murch.one>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 13E76C0032
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 9 Aug 2023 13:13:34 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id ACA1D812AE
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 9 Aug 2023 13:13:33 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org ACA1D812AE
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.597
X-Spam-Level:
X-Spam-Status: No, score=-1.597 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1,
HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, MSGID_FROM_MTA_HEADER=0.001,
NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001]
autolearn=no 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 Cn3jMfL3mH-2
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 9 Aug 2023 13:13:33 +0000 (UTC)
X-Greylist: delayed 400 seconds by postgrey-1.37 at util1.osuosl.org;
Wed, 09 Aug 2023 13:13:32 UTC
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 812D581289
Received: from farbauti.uberspace.de (farbauti.uberspace.de [185.26.156.235])
by smtp1.osuosl.org (Postfix) with ESMTPS id 812D581289
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 9 Aug 2023 13:13:32 +0000 (UTC)
Received: (qmail 31884 invoked by uid 989); 9 Aug 2023 13:06:49 -0000
Authentication-Results: farbauti.uberspace.de;
auth=pass (plain)
Message-ID: <03551f0f-272e-2607-e95a-8ec671cbb9f3@murch.one>
Date: Wed, 9 Aug 2023 15:06:49 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
Thunderbird/102.13.0
Content-Language: en-US
To: bitcoin-dev@lists.linuxfoundation.org
References: <00feb0f1-ec5a-4fc2-8bff-5acf8616e458@app.fastmail.com>
From: Murch <murch@murch.one>
In-Reply-To: <00feb0f1-ec5a-4fc2-8bff-5acf8616e458@app.fastmail.com>
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Rspamd-Bar: --
X-Rspamd-Report: BAYES_HAM(-3) MIME_HTML_ONLY(0.2)
X-Rspamd-Score: -2.8
Received: from unknown (HELO unkown) (::1)
by farbauti.uberspace.de (Haraka/3.0.1) with ESMTPSA;
Wed, 09 Aug 2023 15:06:49 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=murch.one; s=uberspace;
h=from; bh=ynZ2RtArmJdMqS8sTFGcmOFWBEcrYq/NlGp4dpEf+ps=;
b=H7SPW9vy4N9U2tYmqthn6fll78fI9/gwfnIzjpBj70EIkTdiTW5lQk5nOFJe+3moWPt9WUN0G6
tl4TofO6fLMDJzb12ui1q+rVMqRI26Hva7AxDBLnaS0Jsfh7SwKQa+aEjFKudg1x5uezhKZpl647
PmLuErPT0fZBTATAO81JY+68Fg5S0M4w2adkHuTqGmOGtAQaePgd2B7FyoK8lZzGuNY7XvhBzWtI
GDWeThHRZdFRQBV5Cs6ZySs79Vzw/vl4fojHvRIT9ludOSOuBCR67OHhofEC9xh9YdXyCQU09Uts
rEB9EOJPz7pysRcCj6xmu8fZBAPSAC10jNNaUp7eOawbqBbHl4I053n2c4wzjO3v+LlhXQkgkG4w
ZnPAv+hmeqJSqaNhlCKAJw8oXa5wfChxF6oR2sOT+pQdU7QkcTU6WTZf8un1Tx/2fBnb5wwd5tHX
Ok6x6hRxZt4EY8/M0899Df2JRx47ap0ME32BjHDsFpexjRmEff0aoH9ifP8l4/n8XJfyU55QBGCo
fouIGGKY8xBPMPdBRG5wSBW9l+Z1F5VZyvs2VANe2KJl/gze/3hfPr31Evvxge6ZovIe3I1BGbOr
msDyuW2rkBuF5VaUAoZf2y/1OZnN9bgW2hBVUD4865rvd1EvE62FHqb/w9a8SYVvCOmSC/38ISXn
s=
Subject: Re: [bitcoin-dev] Pull-req to remove the arbitrary limits on
OP_Return outputs
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, 09 Aug 2023 13:13:34 -0000
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DUTF=
-8">
</head>
<body>
Hi John,<br>
<br>
On 2023-08-06 16:35, John Light via bitcoin-dev wrote:<br>
<blockquote type=3D"cite">is there ever a case where using OP_RETURN
to embed data actually results in fewer bytes onchain than
embedding the same data using the segwit/taproot witness space</blo=
ckquote>
<br>
Yes, a back-of-the-envelope calculation has me thinking that only
payloads of 135 bytes would be cheaper with transcriptions than with
nulldata outputs. In detail:<br>
<br>
An OP_RETURN output has an overhead of 10 bytes: 8 bytes for the
amount, and a byte each for output script length and OP_RETURN.<br>
<br>
An inscription envelope requires a P2TR output and a P2TR scriptpath
input as overhead. A P2TR output weighs 43 vB, a cursory glance
suggests that the prevalent inscription input seems to be a depth 0
P2TR scriptpath spend where the leaf script consumes a signature via
a CHECKSIG to be followed by the payload envelope. Compared to a
P2TR keypath spend this adds something like 8 WU for the leaf script
and envelope as well as 34 WU for the controlblock. A keypath spend
takes 230 WU, so the total overhead of an inscription lands
somewhere around 111 vB (the additional =E2=80=98ord=E2=80=99 label a=
nd meta header
with encoding information are considered part of the payload here).
After that, the payload gets a discount of 75%.<br>
<br>
Solving <br>
<br>
=C2=A0=C2=A0 =C2=A0111 + 0.25*payload_size =3D 10 + payload_size <br>=
<br>
<p>we learn that nulldata outputs are cheaper up to a payload size
of 134 bytes, only above that inscriptions become a more
blockspace efficient data carrier. <br>
</p>
<p>Further, tooling for OP_RETURNs should be more broadly available
than software that creates inscriptions, so it seems to me that
dropping this limit would make it cheaper to publish certain data
payload sizes to the blockchain, and also make publication of
larger payloads significantly more accessible. Anyway, it=E2=80=99s=
not
obvious to me why we should relax restrictions on publication
mechanisms just because it=E2=80=99s already happening in a differe=
nt
manner (that also only uses blockspace but doesn=E2=80=99t add to t=
he UTXO
set). At that point this proposal neither seems to be a trivial
mempool policy change, nor a clear or significant improvement.
Especially it=E2=80=99s not clear to me, why we should encourage fu=
rther
data publication on the blockchain.<br>
</p>
<p><br>
</p>
On 2023-08-06 16:35, John Light via bitcoin-dev wrote:<br>
<blockquote type=3D"cite">Are there any tools available that a full
node operator could use to prune this data from their nodes? </bloc=
kquote>
<br>
Yes. Running your Bitcoin Core node in prune mode will discard
nulldata outputs when it discards the block.<br>
<br>
<br>
On 2023-08-06 16:35, John Light via bitcoin-dev wrote:<br>
<blockquote type=3D"cite">=C2=A0i) Is the unspendable output pruning
implemented in PR #2791 on by default or is this a flag that needs
to be enabled by full node operators? If it's a flag, what is the
flag called and how can it be enabled? If it's on by default, how
can it be disabled?</blockquote>
<br>
No other special pruning methods beyond pruning of blockchain data
have been implemented in Bitcoin Core. Nor am I aware of any that
have significant benefits over just pruning blockchain data.<br>
<p><br>
</p>
On 2023-08-06 16:35, John Light via bitcoin-dev wrote:<br>
<blockquote type=3D"cite">=C2=A0=C2=A0 ii) If a full node operator do=
es prune
OP_RETURN outputs, does that in any way impair their ability to
help a new node do IBD to validate the blockchain? And would that
answer be any different if we were talking about pruning Taproot
witness space (i.e. "envelopes" or "inscriptions") instead of
OP_RETURN outputs?<br>
</blockquote>
<br>
A transaction from which inscription data or OP_RETURN data has been
removed is incomplete and cannot be validated. If a node operator
were to discard either data, they would not be able to serve
complete blocks and therefore would no longer be able to assist in
IBD.<br>
<p>Given that the proposal is obviously controversial, and the
social media attention this and a few related pull requests have
gotten is already causing brigading, I don=E2=80=99t think it=E2=80=
=99s going to
be a priority for me to further engage with this proposal.</p>
Cheers,<br>
Murch<br>
</body>
</html>
|
