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
|
Delivery-date: Tue, 27 May 2025 10:19:03 -0700
Received: from mail-yb1-f184.google.com ([209.85.219.184])
by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
(Exim 4.94.2)
(envelope-from <bitcoindev+bncBCO6NFWETEOBB7HH27AQMGQEO2USOHA@googlegroups.com>)
id 1uJxx8-0001dC-Co
for bitcoindev@gnusha.org; Tue, 27 May 2025 10:19:03 -0700
Received: by mail-yb1-f184.google.com with SMTP id 3f1490d57ef6-e7d801d48bdsf3474427276.2
for <bitcoindev@gnusha.org>; Tue, 27 May 2025 10:19:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=googlegroups.com; s=20230601; t=1748366336; x=1748971136; darn=gnusha.org;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:references:in-reply-to:message-id:to:from:date:sender:from
:to:cc:subject:date:message-id:reply-to;
bh=ZEK6aOo1J3TLRVKjuR4uIrH770hYi3aAlHgR2KZBnvk=;
b=kgjA8xxuTIWyT4XN8K1kTNmmjy+5KibsODZvwtveyix69yZHH6deiZptsYRAee+y+f
UNftrjarCT2VC3deuRJjVBk90PfI5waWyWdjdK+nJU2yUJJAVbrFx7rgzuKZeMOzZ5B1
hu7Amj8gz8oHFrlzL+XMpr/J3nLFzOSrc64QS8RQupfwcSiNpQ5jnD2mkR4maD0XAsdC
DJX9CGykrtUzSXuisfzIGzYLuhw/co+hE+6b5WrKkqYYtDpuzXXhDREFAYu1sr4VBV2O
TVSuqLas7R5glpdAqF8j+uaeisO64Mk4YQKH0nSAM35Du6lpIEF91D4SuPqRcx2bDlcH
Tqdg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1748366336; x=1748971136; darn=gnusha.org;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:references:in-reply-to:message-id:to:from:date:from:to:cc
:subject:date:message-id:reply-to;
bh=ZEK6aOo1J3TLRVKjuR4uIrH770hYi3aAlHgR2KZBnvk=;
b=iuQamTxQcBGknG4GcvY9cZH3uCGMqqymGuHbHJ8lTWOdTIiUvLsEsIGgh9F/LFLs2E
1SSr+FlLPwkGe1mn9kLagDHDOSdM6q4tVUk23sG+278pxnVhaTReQgsFMEw08TwpLPxA
cgQJa7MZLLe62f88apgi7oqyT67t6IeAwjzUgWs5xDL1Ivnk0sCXrYMoQBxgPNGfP+mG
pfXQv28bV5fy14Kz7J8kLzhmnKBwsBsmsvRHZL31Zme5JThpdpLpZINdeUzEKqPf0vTk
pj/QrfJLUrlETCcA53XfJLaVJUV9g7jxZzLQP3TjrFdtJc/Pw69S98/sbqzCBt+rws5n
D4Vw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1748366336; x=1748971136;
h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
:list-id:mailing-list:precedence:x-original-sender:mime-version
:subject:references:in-reply-to:message-id:to:from:date:x-beenthere
:x-gm-message-state:sender:from:to:cc:subject:date:message-id
:reply-to;
bh=ZEK6aOo1J3TLRVKjuR4uIrH770hYi3aAlHgR2KZBnvk=;
b=XOLdBPdax7DEFkYMQ++8JhDj1Rjag2huVqQ3qKgz/gadN237aKXzEQAIfSbnhgeqAs
sMeMFNHedBy16gUIHp3emaKFToP3MdfJyQ4BqsipCQ23R22xqxvcYmF1x1IEqrWC8Hv3
gJU3+qVkXxc5d8GXcQXonA9TaKcs/uwtFErZ8tF8BVPpLZAkHNgpVS0uQ66GBR2Swzz+
tGDhDWYgrq7lLNC31VV7MEKOWjbvzdBnbE+yRPZMFDDvqcIThoJzVKDMtjsfdaXmo3A4
wavvS7C0DODxdD0UI+viGR+GLYy24brCKtJJdvhliDEwr9ARgEqutGeAGlwYE1Xgsyvp
2Vaw==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCXBolpHwLiLV8ZLNaNwHbcZfNRX7pXHPBLbHRaeKSoSFK125L9J2wT1haOkL3c208fTMt4N3i0vNacE@gnusha.org
X-Gm-Message-State: AOJu0YwLG8SHRW1Qky/V+M7i6insTdTm7kr37EcwAcI1983NwDYEsWch
HDydNuH648sm5CNbmiZnIchXZu9LFvH4NkdYasxUl8TaHsnv+ESC0SmB
X-Google-Smtp-Source: AGHT+IH7KyjuIERytSWAtisjDOsEX2d6YO/z1ZJSYOe5+eUjEdYExryPyqQ6lr9eWguYdiwcMY7tRQ==
X-Received: by 2002:a05:6902:4086:b0:e79:fa4:1439 with SMTP id 3f1490d57ef6-e7d9175b53emr12039870276.9.1748366336446;
Tue, 27 May 2025 10:18:56 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZdxqqH45OUbTjtMU6ObmA6hjjnutR/0L9LrC1LWeF0UVg==
Received: by 2002:a25:7b46:0:b0:e7d:5a87:b47b with SMTP id 3f1490d57ef6-e7d91e5f8b3ls1334132276.0.-pod-prod-01-us;
Tue, 27 May 2025 10:18:52 -0700 (PDT)
X-Received: by 2002:a05:690c:691:b0:6fb:ae6b:a340 with SMTP id 00721157ae682-70e2daa424bmr167792897b3.30.1748366332088;
Tue, 27 May 2025 10:18:52 -0700 (PDT)
Received: by 2002:a0d:de45:0:b0:70e:3f3a:2c12 with SMTP id 00721157ae682-70e3f3a344dms7b3;
Tue, 27 May 2025 09:51:29 -0700 (PDT)
X-Received: by 2002:a05:690c:fc1:b0:70e:779:7e84 with SMTP id 00721157ae682-70e2daa52e8mr182950887b3.27.1748364688228;
Tue, 27 May 2025 09:51:28 -0700 (PDT)
Date: Tue, 27 May 2025 09:51:27 -0700 (PDT)
From: Jonathan Voss <k98kurz@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <a484ae6a-33d6-4704-8356-c0ed1e5ae376n@googlegroups.com>
In-Reply-To: <CAMZUoK=mux6u=f_b0yLb6nvJp41H7iPg7G+dLO5xT94kbDybjQ@mail.gmail.com>
References: <a2fde16d-5ddd-47ae-8b8f-6ca313d92b66n@googlegroups.com>
<CAMZUoK=mux6u=f_b0yLb6nvJp41H7iPg7G+dLO5xT94kbDybjQ@mail.gmail.com>
Subject: Re: [bitcoindev] Proposal to solve the spam war: configurable data
blob relay policy
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_Part_7196_592517075.1748364687869"
X-Original-Sender: K98kurz@gmail.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.5 (/)
------=_Part_7196_592517075.1748364687869
Content-Type: multipart/alternative;
boundary="----=_Part_7197_1216970869.1748364687869"
------=_Part_7197_1216970869.1748364687869
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
My understanding is that Citrea is using a ZKP proof to recover from an=20
invalid protocol state. Whatever data gets into the blockchain, the onus is=
=20
on the Citrea-compatible nodes to do the actual validation -- Bitcoin=20
itself has no part in this other than distributing the data. Adding a new=
=20
relay service for promulgating data that is provably committed to in an=20
OP_RETURN would not be a significant additional burden to the L2 protocol=
=20
if this additional relay service is adopted by a sufficient proportion of=
=20
nodes, and L2 protocol participants would have an incentive to run this new=
=20
relay service for their own benefit, so they would likely already have the=
=20
data cached by the time the transaction is confirmed. I don't have any hard=
=20
numbers on this, but my conjecture is that L2 protocols would run enough=20
relays themselves for the system to be viable, and the clear segregation=20
between arbitrary data ephemerally cached and monetary data permanently=20
stored will be enough incentive for many node operators to also adopt it.
On Tuesday, May 27, 2025 at 12:05:51=E2=80=AFPM UTC-4 Russell O'Connor wrot=
e:
> On Sat, May 24, 2025 at 5:33=E2=80=AFPM Jonathan Voss <k98...@gmail.com> =
wrote:
>
>> However, the recent discussion premised upon Citrea's Clementine Bridge=
=20
>> evidences primarily that the relaying capabilities of the Bitcoin networ=
k=20
>> itself are sufficiently useful for L2 designers that there is an incenti=
ve=20
>> to bypass standardness restrictions for the sake of reliably promulgatin=
g=20
>> data -- at least in the case of Citrea, they say they need to quickly an=
d=20
>> widely disseminate 140+ bytes of arbitrary ZKP data to recover from an=
=20
>> invalid protocol state, and the utility of that ZKP data very quickly=20
>> decreases after it has been confirmed and processed.
>
>
> Does your proposal actually solve this problem? Posting the 140 bytes of=
=20
> data to the blockchain works as a public bulletin board because the actua=
l=20
> data within the block is what is ultimately guaranteed to be disseminated=
=20
> to all participants. With your proposal, a transaction with an OP_RETURN=
=20
> containing a hash of data could end up being mined without the relevant=
=20
> transaction ever even being relayed through the Bitcoin network.
>
>
--=20
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 e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/=
a484ae6a-33d6-4704-8356-c0ed1e5ae376n%40googlegroups.com.
------=_Part_7197_1216970869.1748364687869
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
My understanding is that Citrea is using a ZKP proof to recover from an inv=
alid protocol state. Whatever data gets into the blockchain, the onus is on=
the Citrea-compatible nodes to do the actual validation -- Bitcoin itself =
has no part in this other than distributing the data. Adding a new relay se=
rvice for promulgating data that is provably committed to in an OP_RETURN w=
ould not be a significant additional burden to the L2 protocol if this addi=
tional relay service is adopted by a sufficient proportion of nodes, and L2=
protocol participants would have an incentive to run this new relay servic=
e for their own benefit, so they would likely already have the data cached =
by the time the transaction is confirmed. I don't have any hard numbers on =
this, but my conjecture is that L2 protocols would run enough relays themse=
lves for the system to be viable, and the clear segregation between arbitra=
ry data ephemerally cached and monetary data permanently stored will be eno=
ugh incentive for many node operators to also adopt it.<br /><br /><div cla=
ss=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">On Tuesday, May 2=
7, 2025 at 12:05:51=E2=80=AFPM UTC-4 Russell O'Connor wrote:<br/></div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex; border-left=
: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div dir=3D"ltr"><div d=
ir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr"=
>On Sat, May 24, 2025 at 5:33=E2=80=AFPM Jonathan Voss <<a href data-ema=
il-masked rel=3D"nofollow">k98...@gmail.com</a>> wrote:<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex">However, the recent discussion p=
remised upon Citrea's Clementine Bridge evidences primarily that the re=
laying capabilities of the Bitcoin network itself are sufficiently useful f=
or L2 designers that there is an incentive to bypass standardness restricti=
ons for the sake of reliably promulgating data -- at least in the case of C=
itrea, they say they need to quickly and widely disseminate 140+ bytes of a=
rbitrary ZKP data to recover from an invalid protocol state, and the utilit=
y of that ZKP data very quickly decreases after it has been confirmed and p=
rocessed.</blockquote><div><br></div></div></div></div><div dir=3D"ltr"><di=
v dir=3D"ltr"><div class=3D"gmail_quote">Does your proposal actually solve =
this problem?=C2=A0 Posting the 140 bytes of data to the blockchain works a=
s a public bulletin board because the actual data within the block is what =
is ultimately guaranteed to be disseminated to all participants.=C2=A0 With=
your proposal, a transaction with an OP_RETURN containing a hash of data c=
ould end up being mined without the relevant transaction ever even being re=
layed through the Bitcoin network.</div><br></div>
</div>
</blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/a484ae6a-33d6-4704-8356-c0ed1e5ae376n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/a484ae6a-33d6-4704-8356-c0ed1e5ae376n%40googlegroups.com</a>.<br />
------=_Part_7197_1216970869.1748364687869--
------=_Part_7196_592517075.1748364687869--
|
