From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 02 Dec 2025 05:05:47 -0800 Received: from mail-oa1-f60.google.com ([209.85.160.60]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vQQ4g-0004BT-M3 for bitcoindev@gnusha.org; Tue, 02 Dec 2025 05:05:47 -0800 Received: by mail-oa1-f60.google.com with SMTP id 586e51a60fabf-3ed1781e961sf1260020fac.2 for ; Tue, 02 Dec 2025 05:05:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1764680740; x=1765285540; 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=KFaIh+yzVc6QjIV+cswohUkGrxZ7CvTjHT08GPgTcx0=; b=OCOqRLJ9rcJp2dC3wmwzj4Tw59/NEr0GhIEUp5edVucrQV6zm276Px8qOc1OCdOKCg 9X5AmSSPTXDuznJoqDAAtn7Z2Exd3/5riibgBa9tMBZ01Vz0obB+CbzBkZ6OX8sOnjDr AlT0faJVbi8AmQUnzXWQ3z/TIvEye7LFirzEz+cBzA70XSazeYmhvopnDbZIcDqiD9jC uEOnmbRCprerzffDPo2unXiR3ZbjE4y7pcYG2fdbMbV6FZ+fN4FhJs9MGSz9TNbxsh8+ m9fdQN7p2nNiyCQx9XBPY+Ub/tnlU98Jvr6ZGM178sOV8bF7YTDUmiEoGrq1sqJqUiky fqzQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764680740; x=1765285540; 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=KFaIh+yzVc6QjIV+cswohUkGrxZ7CvTjHT08GPgTcx0=; b=Q4EboUGTK80YbtRPiETZJBYM1vRm+MJbQP//3yTQQ/0s+Ibx9IyH/a9ojq2m+DGVEm ELcbwRNL7z93/ZHUmIrPc1tebPicZb7GU9YZRVGWgSQrqIyvagkqpCgmhjA/Ujba1Vux z1On4UUe/WSQNFNXRWWqqCSb31Wx1nk5C2IcEgHKLiN/Oaqd8/96rYhIp6DxOQDqGvk4 5sKTnJYJdj3tAnH5xoApaX4FeEZu6GHPJ5lZSBsPGfDbNQsuTVMg7wYu/dOqiIcEGU9B 0fCNUExul7X2ei7Fc0P4vionWk2xTBN6+K4CZZEJ6SX8xQnP+NTw/Fn3zfilUftAPJZv Bquw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764680740; x=1765285540; 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=KFaIh+yzVc6QjIV+cswohUkGrxZ7CvTjHT08GPgTcx0=; b=uIziLX/TPixbX/jFXCMveouK7mPXKltSVU/CRlFDOdps5gfnxrfZpBAe1sJ6m55/zU bUiczQkP3dPgLmWEi5/2zWtMmUvFoj9VKiej5bh6rnusQvHgrgSqfDWGIpuIvbPJiRvx PjEqsX4j7qp4pT2jVWU0N65QFGUlZpYKYPRr03bN3NPiVAz5cF1iOJItSpcWaCrzDyeW y0EBYZ+b9YKKPSXimf5ZS5kDUuCkTo24n2ejZBveKzV9T94K2h6vpVXwfJD1TWoejuGY q6+xdhRQS989qZfafFmJ0DAbUXnB0O+wg4D7lEZFAcrkCCnFaoItKNG6epmcr8x2uwH4 PgAQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCW2AWX8rpZKR4RlMIxDLG6LdIELizu7G82Tmr6e1UuiQwMeeB9+8QwNMSZqDUkoNvTi76oAPGe6HGrX@gnusha.org X-Gm-Message-State: AOJu0YxpJXJmSubDO20d5lPp0rpY2tvF1OYf+idEJPEFdIINkDYDqmcd zG89MAJEoUU8ejQnxCAC7hewRrrMvaWvmFsibXIYjN9kMcgwUWXYGEqr X-Google-Smtp-Source: AGHT+IHH/uRQ45RhwjJgTKV5KB4z24NSZfKIyLsdEPsNuOcyKlk67HdGTRtrSvLYHquPnYfUUMxQvA== X-Received: by 2002:a05:6871:3415:b0:3d1:93ab:eaa2 with SMTP id 586e51a60fabf-3ecbe246ccfmr18064547fac.20.1764680740011; Tue, 02 Dec 2025 05:05:40 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+aqIyEImcg2Qzrf2E42V2JOOBg65DWi+sjo1h2B05pwTw==" Received: by 2002:a05:6870:248a:b0:3ec:7947:3f27 with SMTP id 586e51a60fabf-3f0d20b6c3cls2976449fac.0.-pod-prod-01-us; Tue, 02 Dec 2025 05:05:34 -0800 (PST) X-Received: by 2002:a05:6808:238a:b0:450:ccc6:4124 with SMTP id 5614622812f47-45112bb80b4mr17522095b6e.37.1764680734409; Tue, 02 Dec 2025 05:05:34 -0800 (PST) Received: by 2002:a81:fb03:0:b0:786:8d90:70d8 with SMTP id 00721157ae682-78ac3365063ms7b3; Tue, 2 Dec 2025 04:33:43 -0800 (PST) X-Received: by 2002:a05:690c:6606:b0:787:e9bc:fad5 with SMTP id 00721157ae682-78a8b538ccemr366760887b3.33.1764678822675; Tue, 02 Dec 2025 04:33:42 -0800 (PST) Date: Tue, 2 Dec 2025 04:33:42 -0800 (PST) From: waxwing/ AdamISZ To: Bitcoin Development Mailing List Message-Id: <91a40bf7-fe9e-43a1-85d1-5889d4b31a7fn@googlegroups.com> In-Reply-To: References: Subject: Re: [bitcoindev] A safe way to remove objectionable content from the blockchain MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1062634_4854366.1764678822088" X-Original-Sender: ekaggata@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_1062634_4854366.1764678822088 Content-Type: multipart/alternative; boundary="----=_Part_1062635_1561795335.1764678822088" ------=_Part_1062635_1561795335.1764678822088 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable (apologies to OP; we've drifted off topic here). Answers inline. On Monday, December 1, 2025 at 5:36:55=E2=80=AFAM UTC-3 Peter Todd wrote: On Sat, Nov 29, 2025 at 05:54:13AM -0800, waxwing/ AdamISZ wrote:=20 > Hi Peter, list,=20 >=20 > Interesting!=20 >=20 > One thought that springs to mind: attempts to ameliorate IBD with ZKP=20 > should not forget one thing: what we actually want here is succinctness,= =20 > and not so much ZK. Think SNARK instead of ZkSNARK.=20 > Which is important; without the requirement for an actual ZK property for= =20 > the protocol, you can have it have attached witness that is not secret.= =20 The Zero-Knowledge part is important to the goal in this specific use-case:= =20 trying to prevent all arbitrary data publication.=20 Yes agreed. (with the strange caveat: the ZK property itself allows=20 data-embedding almost by force; the reason Schnorr has a data embedding=20 channel and BLS does not is precisely that BLS does not have a ZK property,= =20 which itself relates to the fact that it's deterministic (think: no nonce = =3D=20 no channel) .. the caveat is not super relevant to some kind of ZK-ed IBD= =20 thing, though, since that's compressing an unfathomable amount). =20 =20 It's quite possible that ZKP's are, in the context of decentralized=20 blockchains, an exploit that will prove to be impossible to patch. Similar= =20 to=20 how merge mining is an economic exploit that may well be impossible to=20 patch.=20 Sometimes seemingly good ideas are ultimately killed by clever exploits.=20 I have a sneaking suspicion you're wrong here, but I can't justify it.=20 (Hence 'interesting!'). Would love to hear others opinion on the topic. =20 > Take as contrast the opentimestamps model, where having proof=20 > that something was published, is the main functionality offered/required.= =20 Nope. OpenTimestamps does not use proof of publication at all.=20 OpenTimestamps=20 is a commitment operation: proof that if A was changed, B would have to=20 change=20 too. The vast majority of OTS timestamps are for private data that is never= =20 published in any way. OTS simply shows that data *existed*.=20 That seems like a good correction. So, tamper protection, using binding=20 property of commitments .. and "proof of existence" is *one* possible=20 function? Is that fair? =20 > I=20 > suppose there is another way to say it: the channel counterparty needs=20 > "proof of future publication" in contract setup. That's fair enough but= =20 > it's a very different thing than getting a proof that something *was*=20 > published.=20 It is not a meaningfully different thing. An HTLC is proof that in the=20 event of=20 an uncooperative redemption, publication will happen. Slightly changing the= =20 time it takes is irrelevant to the general concept.=20 Concretely: unless you can propose a technical innovation that somehow=20 turns=20 this pedantic nuance into a meaningfully different implementation, so what?= =20 On reflection I don't see it as strange to make the distinction between the= =20 two: 1/ proof that something was published in the past and 2/ proof that=20 conditional on event X occurring, data Y will be published. I guess 1/ is= =20 just, most realistically, a case of publishing raw, unhashed data on a=20 blockchain, then the proof that that event occurred in the past is the=20 onchain txs ( using op_return or w/e) themselves. As you pointed out,=20 that's not what OTS is doing. Nor is it what an HTLC is doing, that's 2/. --=20 https://petertodd.org 'peter'[:-1]@petertodd.org=20 --=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/= 91a40bf7-fe9e-43a1-85d1-5889d4b31a7fn%40googlegroups.com. ------=_Part_1062635_1561795335.1764678822088 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(apologies to OP; we've drifted off topic here). Answers inline.


On Monday, December 1, 2025 at 5:3= 6:55=E2=80=AFAM UTC-3 Peter Todd wrote:
On Sat, Nov 29, 2025 at 05:54:13AM -0800, waxwing/ AdamISZ wrot= e:
> Hi Peter, list,
>=20
> Interesting!
>=20
> One thought that springs to mind: attempts to ameliorate IBD wit= h ZKP=20
> should not forget one thing: what we actually want here is succi= nctness,=20
> and not so much ZK. Think SNARK instead of ZkSNARK.
> Which is important; without the requirement for an actual ZK pro= perty for=20
> the protocol, you can have it have attached witness that is not = secret.

The Zero-Knowledge part is important to the goal in this specific use= -case:
trying to prevent all arbitrary data publication.

Yes agreed. (with the strange cave= at: the ZK property itself allows data-embedding almost by force; the reaso= n Schnorr has a data embedding channel and BLS does not is precisely that B= LS does not have a ZK property, which itself relates to the fact that it's = deterministic (think: no nonce =3D no channel) .. the caveat is not super r= elevant to some kind of ZK-ed IBD thing, though, since that's compressing a= n unfathomable amount).
=C2=A0
<snip>
= =C2=A0
It's quite possible that ZK= P's are, in the context of decentralized
blockchains, an exploit that will prove to be impossible to patch. Si= milar to
how merge mining is an economic exploit that may well be impossible t= o patch.

Sometimes seemingly good ideas are ultimately killed by clever exploi= ts.

I have a sneaking suspicion you're= wrong here, but I can't justify it. (Hence 'interesting!'). Would love to = hear others opinion on the topic.
=C2=A0
> Take as contrast the opentimestamps model, where ha= ving proof=20
> that something was published, is the main functionality offered/= required.

Nope. OpenTimestamps does not use proof of publication at all. OpenTi= mestamps
is a commitment operation: proof that if A was changed, B would have = to change
too. The vast majority of OTS timestamps are for private data that is= never
published in any way. OTS simply shows that data *existed*.

That seems like a good correction. So, tamper prote= ction, using binding property of commitments .. and "proof of existence" is= *one* possible function? Is that fair?
=C2=A0
> I=20
> suppose there is another way to say it: the channel counterparty= needs=20
> "proof of future publication" in contract setup. That's fair eno= ugh but=20
> it's a very different thing than getting a proof that something = *was*=20
> published.

It is not a meaningfully different thing. An HTLC is proof that in th= e event of
an uncooperative redemption, publication will happen. Slightly changi= ng the
time it takes is irrelevant to the general concept.

Concretely: unless you can propose a technical innovation that someho= w turns
this pedantic nuance into a meaningfully different implementation, so= what?

On reflection I don't see it as st= range to make the distinction between the two: 1/ proof that something was = published in the past and 2/ proof that conditional on event X occurring, d= ata Y will be published. I guess 1/ is just, most realistically, a case of = publishing raw, unhashed data on a blockchain, then the proof that that eve= nt occurred in the past is the onchain txs ( using op_return or w/e) themse= lves. As you pointed out, that's not what OTS is doing. Nor is it what an H= TLC is doing, that's 2/.

--=20
= https://petertodd.org 'peter'[:-1]@petertodd.org

--
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/91a40bf7-fe9e-43a1-85d1-5889d4b31a7fn%40googlegroups.com.
------=_Part_1062635_1561795335.1764678822088-- ------=_Part_1062634_4854366.1764678822088--