From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 To: Bitcoin Development Mailing List Message-Id: In-Reply-To: References: 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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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 = 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.

On Tuesday, May 2= 7, 2025 at 12:05:51=E2=80=AFPM UTC-4 Russell O'Connor wrote:
=
On Sat, May 24, 2025 at 5:33=E2=80=AFPM Jonathan Voss <k98...@gmail.com> wrote:
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.

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.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/a484ae6a-33d6-4704-8356-c0ed1e5ae376n%40googlegroups.com.
------=_Part_7197_1216970869.1748364687869-- ------=_Part_7196_592517075.1748364687869--