From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 09 Dec 2025 14:13:51 -0800 Received: from mail-ot1-f55.google.com ([209.85.210.55]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vT5xu-0000Id-O7 for bitcoindev@gnusha.org; Tue, 09 Dec 2025 14:13:51 -0800 Received: by mail-ot1-f55.google.com with SMTP id 46e09a7af769-7c72ccd60f5sf11248004a34.0 for ; Tue, 09 Dec 2025 14:13:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1765318424; x=1765923224; 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=LotQXzu9nya4JRjuG2sqgQL08e3Uvp8/1hu/mmOM9RA=; b=TCK0IOSh0Q2fl8CM2EpQXc26vOK56HQwWhq0FSEsHTXmJRUbGFV1hoFOaDMG/M4eX3 GLuQzqggOT2QWRvTK/HAP9bcU2TThcw/9dceHoProYoC3FPVCFuewHYJdlgsDhZFOUDH DgsGnuZDL922+T2mndmtnxFRidtFKLB1k6bKC38qj4toNSbpwp5RNp8mT697ZfHCKmW8 UCzzRJ1zvA3uoo/3amEsjIB0vQy0UbRLGgIq/qXks2dgKOVX8adVAiw/Ozdg1sKpf6EE i4FtJSzMj4BpnmNBIoFNY68DqnCrTNWpdgHi3AHmWQnY75jDsGDDt07aSjSW1t7EG9YP QEfg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765318424; x=1765923224; 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=LotQXzu9nya4JRjuG2sqgQL08e3Uvp8/1hu/mmOM9RA=; b=ROT5UzEw5rMx2NB5xHC5+VQknP69ofWqpe7yR296KjR+erzE5cbFDG4mkEl6svfgDh RXbHSl8PWB+kOdtBZcUpbshU9mb0NlLKwBi01KGMDJJV85xHY0ZVRHgWjmOYb9seZ5Ue WupV1KnHkC5bULy3IAGi/6N+ksP2SiQfdAIWdA+WN+5K5lTJW4ts8zeZeeXgpIgf55tQ lNTsDOw2htzRVYG2EVEg/9eS0QgK/S5BCaoGPM7keaEfM3reqenpNsohlcv1UTxBC2na fVAciAE5qdhGx7jqvd3c5wzIgvsSMAAk7N9UDtez7Rxa6ozCk2/a4UE4gHUNcp5bmhNw s6nQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765318424; x=1765923224; 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=LotQXzu9nya4JRjuG2sqgQL08e3Uvp8/1hu/mmOM9RA=; b=uZGvfRes+cin+341l8/wyTEcd4T60ORC4M0qW77N3c3m7R0fGl1Q2brDy8xYdRlVpW VjfCOeYJU1LV0G1OhfuaCLPx6TZccHNE3dxLSAd6FHm0Dq/wvUxFbaPv2c9cK9CHT5tR WrUffSVejYZRA3f7adCjQBhNzN4YH9jBAq0Zn353WEl78yXnQ9iS5mFHe2meO9Hf16uX 4r3ZjRv45YN9KKf3icrQkcFfqg7xf1pAQq5RJgS9rjOEdIUGYdUnkiXZnFJsvYqAAlzJ ug8BRG6KAfl3rUDs8xvReLymZT1gHq0dsLA5MC8BRFlNkOMK03BqAAPVm9XVTp7WWpDc UExA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCUnA1RoTWJmWyoPBo8ysnz5NB2f6hNBg5CU1zcc5txO7ZGsM3F3VXYJ89TH9TNuzseli9iN5VBSVDfs@gnusha.org X-Gm-Message-State: AOJu0Yz2OJ02DoODSjEfShkb0MzivlDvRAqVaBgJp2AxFLjT3qK275T7 wsTUqlQuTOV/Cx5ucPtJzYj29DGANQMd02xq4krTd2UBSzRSi6gGG2PP X-Google-Smtp-Source: AGHT+IH09OrN70iIWXoQFPzsdw8bm9cCfCOBVSNcBRtp97jWQ3q3z/hFWbnj1olw/Z78HrtPiep4Vg== X-Received: by 2002:a05:6820:f024:b0:659:9a49:9062 with SMTP id 006d021491bc7-65b2acd8e80mr225016eaf.45.1765318424323; Tue, 09 Dec 2025 14:13:44 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AWVwgWbLyaCA3+6GOZcotTHLHRs/zeUBvh/zhWJY8qnPzfXQTg==" Received: by 2002:a05:6820:f005:b0:656:cd0e:3c67 with SMTP id 006d021491bc7-65b29e74253ls63292eaf.1.-pod-prod-00-us-canary; Tue, 09 Dec 2025 14:13:39 -0800 (PST) X-Received: by 2002:a05:6808:1b0e:b0:450:cd83:80d6 with SMTP id 5614622812f47-45587562107mr197225b6e.16.1765318419556; Tue, 09 Dec 2025 14:13:39 -0800 (PST) Received: by 2002:a05:690c:768f:b0:786:8d90:70d8 with SMTP id 00721157ae682-78c23b93f22ms7b3; Tue, 9 Dec 2025 11:32:49 -0800 (PST) X-Received: by 2002:a05:690c:6901:b0:786:6076:e8d8 with SMTP id 00721157ae682-78c60ab8ae5mr19808307b3.26.1765308768406; Tue, 09 Dec 2025 11:32:48 -0800 (PST) Date: Tue, 9 Dec 2025 11:32:48 -0800 (PST) From: Boris Nagaev To: Bitcoin Development Mailing List Message-Id: In-Reply-To: References: <91a40bf7-fe9e-43a1-85d1-5889d4b31a7fn@googlegroups.com> Subject: Re: [bitcoindev] A safe way to remove objectionable content from the blockchain MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_633248_1723520447.1765308768000" X-Original-Sender: bnagaev@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_633248_1723520447.1765308768000 Content-Type: multipart/alternative; boundary="----=_Part_633249_930720923.1765308768000" ------=_Part_633249_930720923.1765308768000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi waxwing/AdamISZ, On incentives: agreed that "good" only matters if it's an equilibrium. The= =20 aim is to shape early design choices so the incentive-compatible=20 equilibrium includes DA and forced publication, rather than slipping into a= =20 DA-weak equilibrium where only a few parties hold full data. > what if mining was done just on an accumulator over the utxo set, instead= =20 of the utxo set itself? If miners and nodes only see an UTXO accumulator, how do HTLCs survive? The= =20 HTLC success spend path needs the preimage to be revealed and readable. How= =20 does this fit in an accumulator-only mining model, and what forces=20 publication so the payer can claim its incoming HTLC? Best, Boris On Tuesday, December 9, 2025 at 11:29:24=E2=80=AFAM UTC-3 waxwing/ AdamISZ = wrote: Hi Boris, > To Peter: rather than trying to "defeat ZKP," maybe the pragmatic path=20 is to shape any ZK/succinctness work so that the design itself carries=20 the necessary data (e.g., preimages must be published on-chain and=20 retrievable) and ships with strong data-availability guarantees (so=20 raw tx/block data stays broadly accessible, not just proofs). If the=20 "good" ZK system makes data availability a built-in feature, it can=20 occupy the niche and leave less room for alternative designs that drop=20 those guarantees.=20 re: "a good ZK system makes data availability a built-in feature", I think= =20 this concept of "good" is not very relevant if it's counter to incentives= =20 (hence my earlier "Hmm" comment; incentives matter). Meanwhile I find myself reflecting more on Peter's original point (how=20 spectacularly deleterious to mining this could be, let alone the data=20 availability stuff), and I'm wondering if we can just go radically in the= =20 opposite direction: what if mining was done just on an accumulator over the= =20 utxo set, instead of the utxo set itself? Complete redesign of the=20 protocol, but .. possible, I think? Tx inputs would have to have set=20 membership proofs. I wonder if anyone's done this particular analysis. Cheers, waxwing/AdamISZ On Monday, December 8, 2025 at 2:59:14=E2=80=AFPM UTC-3 Nagaev Boris wrote: Hi waxwing/ AdamISZ,=20 Peter's main concern is that ZKP-only validation can break HTLCs: if a=20 spend is proven valid with a ZK proof but the actual transaction data=20 (including the preimage) never needs to be revealed on-chain, the HTLC=20 payer (the counterparty relying on that preimage) can't learn it and=20 can't claim its incoming HTLC. That undermines Lightning's security=20 because "proof of publication" collapses into "proof of validity=20 without data availability." Any succinctness/ZK approach for Bitcoin=20 has to preserve the guarantee that the preimage is actually published=20 and readable.=20 Related, if the network drifts toward relying on ZK proofs without=20 simultaneously guaranteeing open access to raw blocks and=20 transactions, block data can become gated by a few data providers.=20 That is a data-availability risk that comes with any ZK deployment=20 that omits strong DA, and it would erode self-sovereignty for routing=20 nodes. Any practical ZK/succinctness design for Bitcoin needs strong=20 data availability, so anyone can fetch raw transactions, not just=20 validity proofs.=20 To Peter: rather than trying to "defeat ZKP," maybe the pragmatic path=20 is to shape any ZK/succinctness work so that the design itself carries=20 the necessary data (e.g., preimages must be published on-chain and=20 retrievable) and ships with strong data-availability guarantees (so=20 raw tx/block data stays broadly accessible, not just proofs). If the=20 "good" ZK system makes data availability a built-in feature, it can=20 occupy the niche and leave less room for alternative designs that drop=20 those guarantees.=20 Best,=20 Boris=20 On Tue, Dec 2, 2025 at 10:05=E2=80=AFAM waxwing/ AdamISZ wrote:=20 >=20 > (apologies to OP; we've drifted off topic here). Answers inline.=20 >=20 >=20 > On Monday, December 1, 2025 at 5:36:55=E2=80=AFAM UTC-3 Peter Todd wrote:= =20 >=20 > 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=20 succinctness,=20 > > and not so much ZK. Think SNARK instead of ZkSNARK.=20 > > Which is important; without the requirement for an actual ZK property= =20 for=20 > > the protocol, you can have it have attached witness that is not secret.= =20 >=20 > The Zero-Knowledge part is important to the goal in this specific=20 use-case:=20 > trying to prevent all arbitrary data publication.=20 >=20 >=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 > =20 >=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.=20 Similar to=20 > how merge mining is an economic exploit that may well be impossible to=20 patch.=20 >=20 > Sometimes seemingly good ideas are ultimately killed by clever exploits.= =20 >=20 >=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 >=20 >=20 > > Take as contrast the opentimestamps model, where having proof=20 > > that something was published, is the main functionality=20 offered/required.=20 >=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=20 never=20 > published in any way. OTS simply shows that data *existed*.=20 >=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 >=20 >=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 >=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= =20 the=20 > time it takes is irrelevant to the general concept.=20 >=20 > Concretely: unless you can propose a technical innovation that somehow=20 turns=20 > this pedantic nuance into a meaningfully different implementation, so=20 what?=20 >=20 >=20 > On reflection I don't see it as strange to make the distinction between= =20 the two: 1/ proof that something was published in the past and 2/ proof=20 that conditional on event X occurring, data Y will be published. I guess 1/= =20 is 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 >=20 >=20 > --=20 > https://petertodd.org 'peter'[:-1]@petertodd.org=20 >=20 > --=20 > You received this message because you are subscribed to the Google Groups= =20 "Bitcoin Development Mailing List" group.=20 > To unsubscribe from this group and stop receiving emails from it, send an= =20 email to bitcoindev+...@googlegroups.com.=20 > To view this discussion visit=20 https://groups.google.com/d/msgid/bitcoindev/91a40bf7-fe9e-43a1-85d1-5889d4= b31a7fn%40googlegroups.com.=20 --=20 Best regards,=20 Boris Nagaev=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/= ec60219f-f2c7-4639-8c45-d3f3938241b7n%40googlegroups.com. ------=_Part_633249_930720923.1765308768000 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi waxwing/AdamISZ,

On incentives: agreed t= hat "good" only matters if it's an equilibrium. The aim is to shape early d= esign choices so the incentive-compatible equilibrium includes DA and force= d publication, rather than slipping into a DA-weak equilibrium where only a= few parties hold full data.

>=C2=A0what if m= ining was done just on an accumulator over the utxo set, instead of the utx= o set itself?

If miners and nodes only see an UT= XO accumulator, how do HTLCs survive? The HTLC success spend path needs the= preimage to be revealed and readable.=C2=A0How does this fit in an accumul= ator-only mining model, and what forces publication so the payer can claim = its incoming HTLC?

Best,
Boris
On Tuesday, December 9, 2025 at 11:29:24= =E2=80=AFAM UTC-3 waxwing/ AdamISZ wrote:
Hi Boris,

> To Peter: rath= er than trying to "defeat ZKP," maybe the pragmatic path
is to shape any ZK/succinctness work so that the design itself carrie= s
the necessary data (e.g., preimages must be published on-chain and
retrievable) and ships with strong data-availability guarantees (so
raw tx/block data stays broadly accessible, not just proofs). If the
"good" ZK system makes data availability a built-in feature, it can
occupy the niche and leave less room for alternative designs that dro= p
those guarantees.=C2=A0

re: "a good ZK sys= tem makes data availability a built-in feature", I think this concept of "g= ood" is not very relevant if it's counter to incentives (hence my earlier "= Hmm" comment; incentives matter).
Meanwhile I find myself reflect= ing more on Peter's original point (how spectacularly deleterious to mining= this could be, let alone the data availability stuff), and I'm wondering i= f we can just go radically in the opposite direction: what if mining was do= ne just on an accumulator over the utxo set, instead of the utxo set itself= ? Complete redesign of the protocol, but .. possible, I think? Tx inputs wo= uld have to have set membership proofs. I wonder if anyone's done this part= icular analysis.

Cheers,
waxwing/AdamISZ
On Monday, December 8, 2025 at 2:59:14= =E2=80=AFPM UTC-3 Nagaev Boris wrote:
Hi waxwing/ AdamISZ,

Peter's main concern is that ZKP-only validation can break HTLCs: if = a
spend is proven valid with a ZK proof but the actual transaction data
(including the preimage) never needs to be revealed on-chain, the HTL= C
payer (the counterparty relying on that preimage) can't learn it and
can't claim its incoming HTLC. That undermines Lightning's security
because "proof of publication" collapses into "proof of validity
without data availability." Any succinctness/ZK approach for Bitcoin
has to preserve the guarantee that the preimage is actually published
and readable.

Related, if the network drifts toward relying on ZK proofs without
simultaneously guaranteeing open access to raw blocks and
transactions, block data can become gated by a few data providers.
That is a data-availability risk that comes with any ZK deployment
that omits strong DA, and it would erode self-sovereignty for routing
nodes. Any practical ZK/succinctness design for Bitcoin needs strong
data availability, so anyone can fetch raw transactions, not just
validity proofs.

To Peter: rather than trying to "defeat ZKP," maybe the pragmatic pat= h
is to shape any ZK/succinctness work so that the design itself carrie= s
the necessary data (e.g., preimages must be published on-chain and
retrievable) and ships with strong data-availability guarantees (so
raw tx/block data stays broadly accessible, not just proofs). If the
"good" ZK system makes data availability a built-in feature, it can
occupy the niche and leave less room for alternative designs that dro= p
those guarantees.

Best,
Boris

On Tue, Dec 2, 2025 at 10:05=E2=80=AFAM waxwing/ AdamISZ <ekag...@gmail.com> wrote:
>
> (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 To= dd wrote:
>
> On Sat, Nov 29, 2025 at 05:54:13AM -0800, waxwing/ AdamISZ wrote= :
> > Hi Peter, list,
> >
> > Interesting!
> >
> > One thought that springs to mind: attempts to ameliorate IB= D with ZKP
> > should not forget one thing: what we actually want here is = succinctness,
> > and not so much ZK. Think SNARK instead of ZkSNARK.
> > Which is important; without the requirement for an actual Z= K property for
> > the protocol, you can have it have attached witness that is= not secret.
>
> The Zero-Knowledge part is important to the goal in this specifi= c use-case:
> trying to prevent all arbitrary data publication.
>
>
> Yes agreed. (with the strange caveat: the ZK property itself all= ows data-embedding almost by force; the reason Schnorr has a data embedding= channel and BLS does not is precisely that BLS 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 relevant to some kind of ZK-ed = IBD thing, though, since that's compressing an unfathomable amount).
>
> <snip>
>
>
> It's quite possible that ZKP's are, in the context of decentrali= zed
> blockchains, an exploit that will prove to be impossible to patc= h. Similar to
> how merge mining is an economic exploit that may well be impossi= ble to patch.
>
> Sometimes seemingly good ideas are ultimately killed by clever e= xploits.
>
>
> I have a sneaking suspicion you're wrong here, but I can't justi= fy it. (Hence 'interesting!'). Would love to hear others opinion on the top= ic.
>
>
> > Take as contrast the opentimestamps model, where having pro= of
> > that something was published, is the main functionality off= ered/required.
>
> Nope. OpenTimestamps does not use proof of publication at all. O= penTimestamps
> 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 th= at is never
> published in any way. OTS simply shows that data *existed*.
>
> That seems like a good correction. So, tamper protection, using = binding property of commitments .. and "proof of existence" is *one* possib= le function? Is that fair?
>
>
> > I
> > suppose there is another way to say it: the channel counter= party needs
> > "proof of future publication" in contract setup. That's fai= r enough but
> > it's a very different thing than getting a proof that somet= hing *was*
> > published.
>
> It is not a meaningfully different thing. An HTLC is proof that = in the event of
> an uncooperative redemption, publication will happen. Slightly c= hanging the
> time it takes is irrelevant to the general concept.
>
> Concretely: unless you can propose a technical innovation that s= omehow turns
> this pedantic nuance into a meaningfully different implementatio= n, so what?
>
>
> On reflection I don't see it as strange to make the distinction = between the two: 1/ proof that something was published in the past and 2/ p= roof that conditional on event X occurring, data Y will be published. I gue= ss 1/ is just, most realistically, a case of publishing raw, unhashed data = on a blockchain, then the proof that that event occurred in the past is the= onchain txs ( using op_return or w/e) themselves. As you pointed out, that= 's not what OTS is doing. Nor is it what an HTLC is doing, that's 2/.
>
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
> --
> You received this message because you are subscribed to the Goog= le Groups "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it= , send an email to bitcoindev+...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/b= itcoindev/91a40bf7-fe9e-43a1-85d1-5889d4b31a7fn%40googlegroups.com.



--=20
Best regards,
Boris Nagaev

--
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/ec60219f-f2c7-4639-8c45-d3f3938241b7n%40googlegroups.com.
------=_Part_633249_930720923.1765308768000-- ------=_Part_633248_1723520447.1765308768000--