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
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
|
Return-Path: <vjudeu@gazeta.pl>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 8F91CC0032
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 3 Sep 2023 16:06:13 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 6A61F401DD
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 3 Sep 2023 16:06:13 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 6A61F401DD
Authentication-Results: smtp2.osuosl.org;
dkim=pass (1024-bit key) header.d=gazeta.pl header.i=@gazeta.pl
header.a=rsa-sha256 header.s=2013 header.b=eMhy0w9D
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.686
X-Spam-Level:
X-Spam-Status: No, score=-0.686 tagged_above=-999 required=5
tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001,
RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001, T_MIME_MALF=0.01] autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 5N_UwlvjbK8f
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 3 Sep 2023 16:06:11 +0000 (UTC)
X-Greylist: delayed 300 seconds by postgrey-1.37 at util1.osuosl.org;
Sun, 03 Sep 2023 16:06:11 UTC
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 4B5DC400E4
Received: from smtpo45.poczta.onet.pl (smtpo45.poczta.onet.pl
[213.180.142.176])
by smtp2.osuosl.org (Postfix) with ESMTPS id 4B5DC400E4
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 3 Sep 2023 16:06:11 +0000 (UTC)
Received: from pmq6v.m5r2.onet (pmq6v.m5r2.onet [10.174.33.77])
by smtp.poczta.onet.pl (Onet) with ESMTP id 4RdxML709gzlfc8y;
Sun, 3 Sep 2023 18:01:02 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013;
t=1693756863; bh=IQX7snPIKiw+B64vKlifuLM1C3Y8rg298EJZ6uNI+PU=;
h=From:To:Date:Subject:From;
b=eMhy0w9Dxemxnr3NF4J/BitWPQqnJtzCx+pEV1DQECTr6q7Q+N0Rm1JYXYnFylba7
XdpdQmO/zmVqRSYm0y0ReHjoBZyDzQ5JQYv1Wr/7PlVhTRnq5y5y8WDZFxyl4gGB0S
bKGS0dKFn/KTYzURE/ujsRgpXoDHHs68vUdkTOOY=
Content-Type: multipart/alternative;
boundary="===============3218144798102324546=="
MIME-Version: 1.0
Received: from [5.173.232.248] by pmq6v.m5r2.onet via HTTP id ;
Sun, 03 Sep 2023 18:01:02 +0200
From: vjudeu@gazeta.pl
X-Priority: 3
To: GamedevAlice <gamedevalice256@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
"bitcoin-dev@lists.linuxfoundation.org"
<bitcoin-dev@lists.linuxfoundation.org>
Date: Sun, 03 Sep 2023 18:01:02 +0200
Message-Id: <98009035-ac19029087479e992d1f7eccdc9eb0ab@pmq6v.m5r2.onet>
X-Mailer: onet.poczta
X-Onet-PMQ: <vjudeu@gazeta.pl>;5.173.232.248;PL;2
X-Mailman-Approved-At: Sun, 03 Sep 2023 21:00:46 +0000
Subject: Re: [bitcoin-dev] Concern about "Inscriptions"
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: Sun, 03 Sep 2023 16:06:13 -0000
This is a multi-part message in MIME format.
--===============3218144798102324546==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
> Given the current concerns with blockchain size increases due to inscript=
ions, and now that the lightning network is starting to gain more traction,=
perhaps people are now more willing to consider a smaller blocksize in fav=
or of pushing more activity to lightning?
=C2=A0
People will not agree to shrink the maximum block size. However, if you wan=
t to kill inscriptions, there is another approach, that could be used to fo=
rce them into second layers: it is called cut-through, and was described in=
this topic: https://bitcointalk.org/index.php?topic=3D281848.0
=C2=A0
Then, if you have "Alice -> Bob -> ... -> Zack" transaction chain, and for =
example some inscriptions were created in "Alice -> Bob" transaction, then =
cut-through could remove those inscriptions, while leaving the payment unaf=
fected, because the proper amount of coins will be received by Zack, as it =
should be.
=C2=A0
On 2023-08-25 10:44:41 user GamedevAlice via bitcoin-dev <bitcoin-dev@lists=
.linuxfoundation.org> wrote:
As I understand it, protecting against this is exactly the reason why a blo=
cksize limit exists. Perhaps it should never have been increased in the fir=
st place.
Given the current concerns with blockchain size increases due to inscriptio=
ns, and now that the lightning network is starting to gain more traction, p=
erhaps people are now more willing to consider a smaller blocksize in favor=
of pushing more activity to lightning?
=C2=A0
=C2=A0
=C2=A0
On Tue, Aug 22, 2023, 8:00 AM , <bitcoin-dev-request@lists.linuxfoundation.=
org> wrote:
Send bitcoin-dev mailing list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bitcoin-dev@lists.linuxfoundation.org
To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://lists.linuxfoundation.org/mailman/listi=
nfo/bitcoin-dev
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bitcoin-dev-request@lists.linuxfoundation.org
You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 bitcoin-dev-owner@lists.linuxfoundation.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of bitcoin-dev digest..."
Today's Topics:
=C2=A0 =C2=A01. Re: Concern about "Inscriptions" (symphonicbtc)
----------------------------------------------------------------------
Message: 1
Date: Mon, 21 Aug 2023 22:34:03 +0000
From: symphonicbtc <symphonicbtc@proton.me>
To: John Tromp <john.tromp@gmail.com>
Cc: Bitcoin Protocol Discussion
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Concern about "Inscriptions"
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <UMOgM6dqQHqgxIoeyCE1ZzBDbU1c2H6oyUCVs4eTgUwozD=
phZwFdfO4qvnXUMZwYhfShzcaYqmLGN-XrfzyhYKWD8Q8IOD7EJAtdgbqMLe8=3D@proton.me>
Content-Type: text/plain; charset=3Dutf-8
It is important to also note that proof of secret key schemes are highly da=
ta inefficient and likely would have a higher cost for users than simply al=
lowing arbitrary data to continue. In ECDSA, purposely re-using k values al=
lows you to encode data in both k and the entire secret key, as both become=
computable. Or, one could bruteforce a k value to encode data in a sig, as=
is done in some compromised hardware key exfiltration attacks. Additionall=
y, one can bruteforce keys in order to encode data in the public key.
It is very difficult and expensive to attempt to limit the storage of arbit=
rary data in a system where the security comes from secret keys being arbit=
rary data.
Symphonic
------- Original Message -------
On Monday, August 21st, 2023 at 4:28 PM, John Tromp via bitcoin-dev <bitcoi=
n-dev@lists.linuxfoundation.org> wrote:
> > If we ban "arbitrary data", however you want to define it, then actors =
will
> > simply respond by encoding their data within sets of public keys. Public
> > key data is indistinguishable from random data, and, unless we are will=
ing
> > to pad the blockchain with proof of knowledge of secret keys, there wil=
l be
> > no way to tell a priori whether a given public key is really a public k=
ey
> > or whether it is encoding an inscription or some other data.
>
>
> Note that in the Mimblewimble protocol, range proofs already prove
> knowledge of blinding factor in Pedersen commitments, and thus no
> additional padding is needed there to prevent the encoding of spam
> into cryptographic material. This makes pure MW blockchains the most
> inscription/spam resistant [1].
>
> [1] https://bitcointalk.org/index.php?topic=3D5437464.msg61980991#msg6198=
0991
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
------------------------------
Subject: Digest Footer
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
------------------------------
End of bitcoin-dev Digest, Vol 99, Issue 43
*******************************************
--===============3218144798102324546==
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
<div>
<div>> Given the current concerns with blockchain size increases due to =
inscriptions, and now that the lightning network is starting to gain more t=
raction, perhaps people are now more willing to consider a smaller blocksiz=
e in favor of pushing more activity to lightning?</div>
<div> </div>
<div>People will not agree to shrink the maximum block size. However, if yo=
u want to kill inscriptions, there is another approach, that could be used =
to force them into second layers: it is called cut-through, and was describ=
ed in this topic: <a href=3D"https://bitcointalk.org/index.php?topic=3D2818=
48.0" target=3D"_blank" rel=3D"noopener">https://bitcointalk.org/index.php?=
topic=3D281848.0</a></div>
<div> </div>
<div>Then, if you have "Alice -> Bob -> ... -> Zack" transaction c=
hain, and for example some inscriptions were created in "Alice -> Bob" t=
ransaction, then cut-through could remove those inscriptions, while leaving=
the payment unaffected, because the proper amount of coins will be receive=
d by Zack, as it should be.</div>
<br /><br /></div>
<div> </div>
<div>On 2023-08-25 10:44:41 user GamedevAlice via bitcoin-dev <bitcoin-d=
ev@lists.linuxfoundation.org> wrote:</div>
<blockquote style=3D"margin-right: 0; margin-left: 7px; border-left: 2px so=
lid orange; padding-left: 8px;">
<div dir=3D"auto">As I understand it, protecting against this is exactly th=
e reason why a blocksize limit exists. Perhaps it should never have been in=
creased in the first place.
<div dir=3D"auto"><br />
<div dir=3D"auto">Given the current concerns with blockchain size increases=
due to inscriptions, and now that the lightning network is starting to gai=
n more traction, perhaps people are now more willing to consider a smaller =
blocksize in favor of pushing more activity to lightning?</div>
<div dir=3D"auto"> </div>
<div dir=3D"auto"> </div>
<div dir=3D"auto"> </div>
</div>
</div>
<br />
<div class=3D"gmail_quote">
<div class=3D"gmail_attr" dir=3D"ltr">On Tue, Aug 22, 2023, 8:00 AM , <<=
a href=3D"mailto:bitcoin-dev-request@lists.linuxfoundation.org" target=3D"_=
blank" rel=3D"noopener">bitcoin-dev-request@lists.linuxfoundation.org</a>&g=
t; wrote:</div>
<blockquote class=3D"gmail_quote" style=3D"margin: 0 0 0 .8ex; border-left:=
1px #ccc solid; padding-left: 1ex;">Send bitcoin-dev mailing list submissi=
ons to<br /> <a href=3D"mailto:bitcoin-dev@lists=
.linuxfoundation.org" target=3D"_blank" rel=3D"noopener noreferrer">bitcoin=
-dev@lists.linuxfoundation.org</a><br /><br />To subscribe or unsubscribe v=
ia the World Wide Web, visit<br /> <a href=3D"ht=
tps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" target=3D"_bl=
ank" rel=3D"noopener noreferrer noreferrer">https://lists.linuxfoundation.o=
rg/mailman/listinfo/bitcoin-dev</a><br />or, via email, send a message with=
subject or body 'help' to<br /> <a href=3D"mail=
to:bitcoin-dev-request@lists.linuxfoundation.org" target=3D"_blank" rel=3D"=
noopener noreferrer">bitcoin-dev-request@lists.linuxfoundation.org</a><br /=
><br />You can reach the person managing the list at<br /> &nb=
sp; <a href=3D"mailto:bitcoin-dev-owner@lists.linuxfoundation.org" t=
arget=3D"_blank" rel=3D"noopener noreferrer">bitcoin-dev-owner@lists.linuxf=
oundation.org</a><br /><br />When replying, please edit your Subject line s=
o it is more specific<br />than "Re: Contents of bitcoin-dev digest..."<br =
/><br /><br />Today's Topics:<br /><br /> 1. Re: Concern about =
"Inscriptions" (symphonicbtc)<br /><br /><br />----------------------------=
------------------------------------------<br /><br />Message: 1<br />Date:=
Mon, 21 Aug 2023 22:34:03 +0000<br />From: symphonicbtc <<a href=3D"mai=
lto:symphonicbtc@proton.me" target=3D"_blank" rel=3D"noopener noreferrer">s=
ymphonicbtc@proton.me</a>><br />To: John Tromp <<a href=3D"mailto:joh=
n.tromp@gmail.com" target=3D"_blank" rel=3D"noopener noreferrer">john.tromp=
@gmail.com</a>><br />Cc: Bitcoin Protocol Discussion<br /> =
<<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
target=3D"_blank" rel=3D"noopener noreferrer">bitcoin-dev@lists.linuxfounda=
tion.org</a>><br />Subject: Re: [bitcoin-dev] Concern about "Inscription=
s"<br />Message-ID:<br /> <UMOgM6dqQHqgxIoeyC=
E1ZzBDbU1c2H6oyUCVs4eTgUwozDphZwFdfO4qvnXUMZwYhfShzcaYqmLGN-XrfzyhYKWD8Q8IO=
D7EJAtdgbqMLe8=3D@<a href=3D"http://proton.me" target=3D"_blank" rel=3D"noo=
pener noreferrer noreferrer">proton.me</a>><br /><br />Content-Type: tex=
t/plain; charset=3Dutf-8<br /><br />It is important to also note that proof=
of secret key schemes are highly data inefficient and likely would have a =
higher cost for users than simply allowing arbitrary data to continue. In E=
CDSA, purposely re-using k values allows you to encode data in both k and t=
he entire secret key, as both become computable. Or, one could bruteforce a=
k value to encode data in a sig, as is done in some compromised hardware k=
ey exfiltration attacks. Additionally, one can bruteforce keys in order to =
encode data in the public key.<br /><br />It is very difficult and expensiv=
e to attempt to limit the storage of arbitrary data in a system where the s=
ecurity comes from secret keys being arbitrary data.<br /><br />Symphonic<b=
r /><br />------- Original Message -------<br />On Monday, August 21st, 202=
3 at 4:28 PM, John Tromp via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@=
lists.linuxfoundation.org" target=3D"_blank" rel=3D"noopener noreferrer">bi=
tcoin-dev@lists.linuxfoundation.org</a>> wrote:<br /><br /><br />> &g=
t; If we ban "arbitrary data", however you want to define it, then actors w=
ill<br />> > simply respond by encoding their data within sets of pub=
lic keys. Public<br />> > key data is indistinguishable from random d=
ata, and, unless we are willing<br />> > to pad the blockchain with p=
roof of knowledge of secret keys, there will be<br />> > no way to te=
ll a priori whether a given public key is really a public key<br />> >=
; or whether it is encoding an inscription or some other data.<br />> <b=
r />> <br />> Note that in the Mimblewimble protocol, range proofs al=
ready prove<br />> knowledge of blinding factor in Pedersen commitments,=
and thus no<br />> additional padding is needed there to prevent the en=
coding of spam<br />> into cryptographic material. This makes pure MW bl=
ockchains the most<br />> inscription/spam resistant [1].<br />> <br =
/>> [1] <a href=3D"https://bitcointalk.org/index.php?topic=3D5437464.msg=
61980991#msg61980991" target=3D"_blank" rel=3D"noopener noreferrer noreferr=
er">https://bitcointalk.org/index.php?topic=3D5437464.msg61980991#msg619809=
91</a><br />> _______________________________________________<br />> =
bitcoin-dev mailing list<br />> <a href=3D"mailto:bitcoin-dev@lists.linu=
xfoundation.org" target=3D"_blank" rel=3D"noopener noreferrer">bitcoin-dev@=
lists.linuxfoundation.org</a><br />> <a href=3D"https://lists.linuxfound=
ation.org/mailman/listinfo/bitcoin-dev" target=3D"_blank" rel=3D"noopener n=
oreferrer noreferrer">https://lists.linuxfoundation.org/mailman/listinfo/bi=
tcoin-dev</a><br /><br /><br />------------------------------<br /><br />Su=
bject: Digest Footer<br /><br />___________________________________________=
____<br />bitcoin-dev mailing list<br /><a href=3D"mailto:bitcoin-dev@lists=
.linuxfoundation.org" target=3D"_blank" rel=3D"noopener noreferrer">bitcoin=
-dev@lists.linuxfoundation.org</a><br /><a href=3D"https://lists.linuxfound=
ation.org/mailman/listinfo/bitcoin-dev" target=3D"_blank" rel=3D"noopener n=
oreferrer noreferrer">https://lists.linuxfoundation.org/mailman/listinfo/bi=
tcoin-dev</a><br /><br /><br />------------------------------<br /><br />En=
d of bitcoin-dev Digest, Vol 99, Issue 43<br />****************************=
***************</blockquote>
</div>
</blockquote>
--===============3218144798102324546==--
|
