From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 29 Nov 2025 05:57:41 -0800 Received: from mail-ot1-f62.google.com ([209.85.210.62]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vPLSG-0006AU-FR for bitcoindev@gnusha.org; Sat, 29 Nov 2025 05:57:41 -0800 Received: by mail-ot1-f62.google.com with SMTP id 46e09a7af769-7c7593b5c93sf2809621a34.3 for ; Sat, 29 Nov 2025 05:57:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1764424654; x=1765029454; 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=N9DoVZM1Pj6StC/UwS9G6zZHN0h4vpfFFnFoY4mQKOM=; b=BhORIJEfHxQPVaZS8HYWzN07qlCQI1NCj4u+uE4Ld8qJpr0/0YV2VX0FBcbn4ZoQLW Dof2fbHogpbyyOHtHU4xPy6c6k+1akFlpSRo42zMOikIL3PSVgofnFbXc6GqxJnEjUFi c8FnHElPt2jkOsGc15EGkrmqN8c0Ux8uu2iaOkDOrShjIR5w7aVYXZTD4AkZZ7DJ/qh9 AUPp0yvu7dLw01XTy0/EclzgZmI0MBXxuBwQ0uXvyzd6G2RW7mHR4CzI2TnxAF/gSLyt kI4xj56R10zSEyvo7bk74s0K381iI3y7gsf/rh8coKWqfBkBk8qTaYSckxvCWxMEHNDN xReQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764424654; x=1765029454; 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=N9DoVZM1Pj6StC/UwS9G6zZHN0h4vpfFFnFoY4mQKOM=; b=RRuKVtBM8k748qa/agx25KSZ/DmSRuVmN0YFv5p+on4LhPlEQwX1LK4GLfQ+Pxgp0x /cEtaI/0dyyVAkRQNxAULuFmAkkV5X+6yS4lW1tfb/R9PKhFefnJtWfxaf5GL/l9Anc+ wDh5TzRQy2K/mWaQJlYZX12Sy9YQ7OsxMCYQJhhTPKPJLCY1gM6OzfZyFGCk1xvOt5Vu 5WHUK9jea+mMAcWa74H6drp8HNegV+b6o+4120YIoTjBctaM6Qz19uw1xDERmQL7kbip ZE6U0FYLrY18DDzzn33g2a3HOm+/Sy/CO1nFbUvQJZjd8tmNWJG78dT1uG3WnLC1D+EZ AVXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764424654; x=1765029454; 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=N9DoVZM1Pj6StC/UwS9G6zZHN0h4vpfFFnFoY4mQKOM=; b=Juq6pSURKDkYSFJpkzSmuy9DdbkUUOy2ILX0NuAHZPsp3DxgufCizqfDR7G4vAXumo 2DjrWQ0tB4iW+DD7EBhv1Z9N5OnHT9qXutfHFlgX3BN+Op0dlJYRo1WRyA2RP9Yy9cAQ oQUsqqazGJFX2OvO7s6VhwH5t4q4rLNR8Jnu/Bu/a6wHQIfHy0oAonCgYWnH2bcU7XwO I/3m6yJ5/5PmH+y5y7MdcVoK1HvxrEydxHtaOlZ3KQnTJ/aX3mlz7PZzpUjg6L3BpNPO FKX2kueTXkJkbNvBl9TTXuCNdLqzGDoocFlIIn0qk62Uf7KflDSBlN4xmPCmn7LgyOeh DncA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCVI05Wu4Fbvgkljpn+I3vpgKJ8fFEP/AeOQdFW/Y/Sjx/2e3GuQv25MWVeIIgPBSSPNeiwFCeM6sy/L@gnusha.org X-Gm-Message-State: AOJu0YxMeOd1TZEcCPzipz/haDbYtir62Ghjs6eBTrvfFzH6i/F5wpgJ 9M+ftLHfu9BkUrJYH0k3mij2bi5K3is6i5xnmZMKxmvo1dJ6XSgzFc91 X-Google-Smtp-Source: AGHT+IGEtLKNrvocHpPMybowsy7ImljKF/G6n4/4ayhFowMAJ2Een4YXcJ4u/hAYE8jrhlh8Z50JVA== X-Received: by 2002:a05:6808:c39d:b0:44f:775b:729f with SMTP id 5614622812f47-45112a8d82bmr9073719b6e.28.1764424653869; Sat, 29 Nov 2025 05:57:33 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+YlWc7rywFeDlGZNzMDZXHep9A1q2vE4FvASXRWTo+tbw==" Received: by 2002:a05:6870:248a:b0:3ec:7947:3f27 with SMTP id 586e51a60fabf-3f0d20b6c3cls1489457fac.0.-pod-prod-01-us; Sat, 29 Nov 2025 05:57:28 -0800 (PST) X-Received: by 2002:a05:6808:3086:b0:450:3124:53b7 with SMTP id 5614622812f47-45112d663damr15069360b6e.67.1764424648665; Sat, 29 Nov 2025 05:57:28 -0800 (PST) Received: by 2002:a81:fb03:0:b0:786:8d90:70d8 with SMTP id 00721157ae682-78ac3365063ms7b3; Sat, 29 Nov 2025 05:54:14 -0800 (PST) X-Received: by 2002:a05:690c:e1e:b0:786:5212:4a7b with SMTP id 00721157ae682-78a8b568258mr238114537b3.58.1764424453799; Sat, 29 Nov 2025 05:54:13 -0800 (PST) Date: Sat, 29 Nov 2025 05:54:13 -0800 (PST) From: waxwing/ AdamISZ To: Bitcoin Development Mailing List Message-Id: 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_525056_869807458.1764424453387" 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_525056_869807458.1764424453387 Content-Type: multipart/alternative; boundary="----=_Part_525057_2083856786.1764424453387" ------=_Part_525057_2083856786.1764424453387 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Peter, list, Interesting! 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. 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. Then a counter-thought strikes, that any version of these protocols that=20 requires more data/bandwidth probably loses out to versions that have less= =20 data/bandwidth. Hmm. It seems to demonstrate, to me, that some kind of "data carrying" is=20 required in the "state" (cf the "history"). Ironically recent discussion=20 (see 'On (in)ability to embed data into Schnorr' but yeah a googolplex of= =20 "discussions" on the internet about filtering and spam...) has just=20 re-emphasized that the utxo set can inevitably carry data (I guess that's= =20 obvious). I do think, long term that ZKP over history is correct, and that (see=20 typical rollup design) data carrying in state can do the job that you are= =20 (correctly) insisting, must be done. (And the corollary: "harmful data on the blockchain" is a wrong mental=20 model and should be abandoned, irrespective of architecture.) Aside from your *main* concept here, I think the idea that HTLCs require=20 *proof* of publication is wrong. What they require is publication. A=20 wronged channel party needs to read the preimage, not have proof that it=20 can be read. Take as contrast the opentimestamps model, where having proof= =20 that something was published, is the main functionality offered/required. 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. Cheers, AdamISZ/waxwing On Saturday, November 29, 2025 at 8:32:21=E2=80=AFAM UTC-3 Peter Todd wrote= : > On Thu, Nov 20, 2025 at 04:21:33PM -0500, Ethan Heilman wrote: > > I'm not convinced your hash function approach fully does what you want = it > > to, although it does seem doable with some additional constraints. > >=20 > > There is a solution that does everything you want it and more, ZKPs. > >=20 > > ZKP (Zero Knowledge Proofs) can prove that some data X hashes to some= =20 > hash > > output Y while keeping the actual value X secret. Thus, everyone can be > > convinced that H(X) =3D Y even if X is deleted and no one knows what th= e > > value X was. > >=20 > > Even more exciting, ZKPs can prove the correctness and validity of the > > entire Bitcoin blockchain. Thus storing old transactions is > > no longer needed to convince others that the chain is correct. This wou= ld > > remove any harmful data. Zerosync in 2017 compressed Bitcoin's blockcha= in > > into a 800 KB proof [0] which is constant size regardless of the number= =20 > of > > transactions or bytes compressed. This approach does not require any > > changes to Bitcoin and you could implement a Bitcoin full node today th= at > > supports this. > >=20 > > We have a solution to solve the problem of harmful data on the blockcha= in > > since 2017. It just requires time, money and motivated people to work o= n=20 > it. > > Rather than being a solution, the technology behind Zerosync is a potenti= al > threat to Bitcoin. The problem is that Bitcoin fundamentally requires > proof-of-publication to be decentralized and censorship resistant; a=20 > related > problem is that HTLCs (and thus Lightning) fundamentally requires > proof-of-publication to work at all. > > For Bitcoin mining to remain decentralized, blocks need to be widely=20 > propagated > in a form suitable for creating new blocks. ZKP/Zerosync makes it possibl= e=20 > to > prove that a block hash and all prior blocks follow the protocol rules an= d=20 > were > thus valid. However, valid block hashes alone are insufficient to mine on= =20 > top > of because they do not contain the UTXO set data necessary to mine a new= =20 > block. > > Why do miners have an incentive to distribute the blocks they find?=20 > Ultimately > because doing so is necessary for the coins they mined to be valuable. Bu= t=20 > if > full nodes can be convinced of the validity of coins without full block > contents --- thus allowing those coins to be sold --- that weakens the > incentives to distribute block data in a form that allows other miners to= =20 > mine. > > > With regard to HTLCs/Lightning, HTLCs rely on a proof-of-publication to b= e > secure: for the HTLC to be redeemed, the redeemer *must* publish the=20 > pre-image > in the Bitcoin chain, allowing the other party relying on the HTLC to=20 > recover > the pre-image. Again, ZKP/Zerosync weakens this security, as the validity= =20 > of > the transaction spending the HTLC can be proven without actually making t= he > pre-image available. > > > Rather than presenting ZKP/Zerosync as a solution to the "harmful data" > problem, we should in fact be researching ways to defeat ZKP/Zerosync=20 > entirely. > We need a consensus protocol where the only way to fully validate a block= =20 > is to > actually have the entire block contents. > > As for "harmful data", that is a challenge to be solved=20 > legally/politically. > > --=20 > https://petertodd.org 'peter'[:-1]@petertodd.org > --=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/= f5cf7fb8-61ce-437b-b26b-241d47b3fcb5n%40googlegroups.com. ------=_Part_525057_2083856786.1764424453387 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Peter, list,

Interesting!

One thought that springs to mind: attempts to ameliorate IBD w= ith ZKP should not forget one thing: what we actually want here is succinct= ness, and not so much ZK. Think SNARK instead of ZkSNARK.
Which i= s important; without the requirement for an actual ZK property for the prot= ocol, you can have it have attached witness that is not secret.
<= br />
Then a counter-thought strikes, that any version of these p= rotocols that requires more data/bandwidth probably loses out to versions t= hat have less data/bandwidth. Hmm.

=C2=A0It seem= s to demonstrate, to me, that some kind of "data carrying" is required in t= he "state" (cf the "history"). Ironically recent discussion (see 'On (in)ab= ility to embed data into Schnorr' but yeah a googolplex of "discussions" on= the internet about filtering and spam...) has just re-emphasized that the = utxo set can inevitably carry data (I guess that's obvious).

I do think, long term that ZKP over history is correct, and th= at (see typical rollup design) data carrying in state can do the job that y= ou are (correctly) insisting, must be done.
(And the corollary: "= harmful data on the blockchain" is a wrong mental model and should be aband= oned, irrespective of architecture.)

Aside from = your *main* concept here, I think the idea that HTLCs require *proof* of pu= blication is wrong. What they require is publication. A wronged channel par= ty needs to read the preimage, not have proof that it can be read. Take as = contrast the opentimestamps model, where having proof that something was pu= blished, is the main functionality offered/required. I suppose there is ano= ther way to say it: the channel counterparty needs "proof of future publication" in contract setup. That's fair enough but it's a very different thing than getting a proof that something *was*=20 published.

Cheers,
AdamISZ/waxwing

On Saturday, November 29, 2025 at 8:32:21=E2=80=AFAM UTC-3 Peter = Todd wrote:
O= n Thu, Nov 20, 2025 at 04:21:33PM -0500, Ethan Heilman wrote:
> I'm not convinced your hash function approach fully does what = you want it
> to, although it does seem doable with some additional constraints.
>=20
> There is a solution that does everything you want it and more, ZKP= s.
>=20
> ZKP (Zero Knowledge Proofs) can prove that some data X hashes to s= ome hash
> output Y while keeping the actual value X secret. Thus, everyone c= an be
> convinced that H(X) =3D Y even if X is deleted and no one knows wh= at the
> value X was.
>=20
> Even more exciting, ZKPs can prove the correctness and validity of= the
> entire Bitcoin blockchain. Thus storing old transactions is
> no longer needed to convince others that the chain is correct. Thi= s would
> remove any harmful data. Zerosync in 2017 compressed Bitcoin's= blockchain
> into a 800 KB proof [0] which is constant size regardless of the n= umber of
> transactions or bytes compressed. This approach does not require a= ny
> changes to Bitcoin and you could implement a Bitcoin full node tod= ay that
> supports this.
>=20
> We have a solution to solve the problem of harmful data on the blo= ckchain
> since 2017. It just requires time, money and motivated people to w= ork on it.

Rather than being a solution, the technology behind Zerosync is a poten= tial
threat to Bitcoin. The problem is that Bitcoin fundamentally requires
proof-of-publication to be decentralized and censorship resistant; a re= lated
problem is that HTLCs (and thus Lightning) fundamentally requires
proof-of-publication to work at all.

For Bitcoin mining to remain decentralized, blocks need to be widely pr= opagated
in a form suitable for creating new blocks. ZKP/Zerosync makes it possi= ble to
prove that a block hash and all prior blocks follow the protocol rules = and were
thus valid. However, valid block hashes alone are insufficient to mine = on top
of because they do not contain the UTXO set data necessary to mine a ne= w block.

Why do miners have an incentive to distribute the blocks they find? Ult= imately
because doing so is necessary for the coins they mined to be valuable. = But if
full nodes can be convinced of the validity of coins without full block
contents --- thus allowing those coins to be sold --- that weakens the
incentives to distribute block data in a form that allows other miners = to mine.


With regard to HTLCs/Lightning, HTLCs rely on a proof-of-publication to= be
secure: for the HTLC to be redeemed, the redeemer *must* publish the pr= e-image
in the Bitcoin chain, allowing the other party relying on the HTLC to r= ecover
the pre-image. Again, ZKP/Zerosync weakens this security, as the validi= ty of
the transaction spending the HTLC can be proven without actually making= the
pre-image available.


Rather than presenting ZKP/Zerosync as a solution to the "harmful = data"
problem, we should in fact be researching ways to defeat ZKP/Zerosync e= ntirely.
We need a consensus protocol where the only way to fully validate a blo= ck is to
actually have the entire block contents.

As for "harmful data", that is a challenge to be solved legal= ly/politically.

--=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/f5cf7fb8-61ce-437b-b26b-241d47b3fcb5n%40googlegroups.com.
------=_Part_525057_2083856786.1764424453387-- ------=_Part_525056_869807458.1764424453387--