From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 29 Nov 2025 07:44:04 -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 1vPN7C-0007Ol-Un for bitcoindev@gnusha.org; Sat, 29 Nov 2025 07:44:04 -0800 Received: by mail-oa1-f60.google.com with SMTP id 586e51a60fabf-3e890e6be00sf4475318fac.3 for ; Sat, 29 Nov 2025 07:44:02 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1764431037; cv=pass; d=google.com; s=arc-20240605; b=aVQAmiIazUHGAtw5vXcRotet92qCdnawnZNusymb6/Ut74/yEq1ntG+Qx37N56Bmms ehYXtkZVBL2D0+w3i1oUI7IOAvDWNOC69qCcf8vransMlecIZ2yJtE3bbTaSpbKxVmWm HVS26nTkf26TIkm0e6ltHeeaP/KS8sDKJSe/qzIXjpRzqEZjXAylzbMm0BJJSRrlUO0G QH0TbOGvUR+u6Ddcg1mYhBJNTMCqVzfZ8HE8e5EHwAJWKB76cglmZIxI9HdfSYiWlhhe c1vWODv6KGD8KdUILUk94jVpQGrzqV9oDwxeq5BL8AteFTeJAg7VTKcP6VYtlw1kGzqo NCMA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature; bh=Gap64vNkrq7/MrfI1CK2fAkSqp7Ou9pg/3MsLu1MNq0=; fh=MasCO7fGsLPpoGc66gf5FKBHjBIPVXI7lt3axxligWs=; b=Rb+BjspDxIWxXgRBkSI+O9DyruMmy/X6+T9nwkemOXt1ntPSp5ncMTWdmiZojrqvDp ZHEIg4N+E9LrFbA7N/D9MTBOTdgBEQ37OuVlsz+qse470NbIl5bpJjbNfqSS2CTrnyAE BiULFoLjpLCTBPFfuhq79IZOEu5QUdiRsl16Wr6IkiBtdMKfmmutrI8Jtaa2YBF6HW22 KYfj1vTPvSvoyST94DIhyuWFK9GNpmfIB30L/7ObrVZphoiesb6QFgvzmRORJPicsy7i RpH327Mqhmd1iDFBWX8J3XVslGL/wCaQyC2lrT7UNizp9n9urIlKLC0PyIuIraj3WLKd o1Ng==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@q32-com.20230601.gappssmtp.com header.s=20230601 header.b=ypegZeyl; spf=pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::62e as permitted sender) smtp.mailfrom=earonesty@gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1764431037; x=1765035837; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=Gap64vNkrq7/MrfI1CK2fAkSqp7Ou9pg/3MsLu1MNq0=; b=Kaqnclb5ME682vIA5mhTQZwIRBcMNNrJb2hHhj288am6phyQFkuWZqVdFBoyli2xRP sU5iJddCtheoB0mRXenymRS4PUsqf34qeqrxVkho81jJQN51RugyV3uOZ7eH/xEdyFmw p7CNIIdBPB8yqvl/jSy2qz66zTCE87V2hZr9kBdM+Mxjfo/RCBMLZN6VK2GwTOXTWBA8 XvEchnKoABdyqLBNRcTLm28gkwr5+WwoZ71soX+x7Mz4eyOxOroyLhVX3cKN4OB7Jh3J 8qFx4iIajHRyXjZgHzrkIkkegurTZZ6opn7X9C1EbbwfUJ2+UeAGFa1s0mh+Z+sdtNmv vEZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764431037; x=1765035837; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=Gap64vNkrq7/MrfI1CK2fAkSqp7Ou9pg/3MsLu1MNq0=; b=MP7gq5VkN2go2pXWWFIn2jzf4U9FJ3r2ESt/JDZ0TIOayl3mW6eqQJgieHEKW7IB5+ B08/J6lVDRZ3XMnUXugz6YIFI3gIhiSjybDS91XBO1o+/NWhkRPce87P+8FF9pj+8TTM Z/oRx8uk0VTvG0qr3VdDqhoIvSM07Wlf8VKXp9KQa9HiIG14gcPidz0fAW0IC/HLeTse tsHU61K0kGrlGfmnjePfu4ks9d0H7eMuH5sVH6zFVq4scsYATWd+hRpJlKeDwDHLcmnJ Uj9/q776tOg1EwtlxFkVkESavid8U8TORP8h5L7S9mo1/OHBMX16I2GlIn84jOTxTDUy rdRg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCUbcsnqTzx+NCW6AxtHU0++Efji/VFpJNsNy5fe0pRgOS4k2nBoLW2j39nH6n5iZaJZSRLJ9Zwk2DYW@gnusha.org X-Gm-Message-State: AOJu0Yyw8sQD0Zys6QziqdycxV1q3+Vuu7JSugjUQYEvUCsK2r3uOLt0 0VNlC6QJ8yahQT5Z6FiwtweiVowYC2ntHAv/nB07P/4pJVkGjTdhHLma X-Google-Smtp-Source: AGHT+IGExXb7tY6p1x8dyehwTrBc54aJ5k6us/xgUnN71rWg3LPR1K1zjG91ba0teX3SdbgROuxPrg== X-Received: by 2002:a05:6870:6b97:b0:3ea:9b60:d511 with SMTP id 586e51a60fabf-3ed1fff622emr10058319fac.40.1764431036637; Sat, 29 Nov 2025 07:43:56 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+bunsXBZBMdmVSRSl4age9HMVysr2BdWBCEJc9ZifRp3A==" Received: by 2002:a05:6870:cc82:b0:3ea:9b4e:cb29 with SMTP id 586e51a60fabf-3f0d2705bc0ls2381997fac.2.-pod-prod-08-us; Sat, 29 Nov 2025 07:43:51 -0800 (PST) X-Received: by 2002:a05:6808:1185:b0:450:760b:cc98 with SMTP id 5614622812f47-4514e5fa4a6mr7906050b6e.14.1764431031182; Sat, 29 Nov 2025 07:43:51 -0800 (PST) Received: by 2002:a05:6402:3088:b0:641:820c:7d45 with SMTP id 4fb4d7f45d1cf-645fc077e72msa12; Sat, 29 Nov 2025 07:41:42 -0800 (PST) X-Received: by 2002:a17:906:fe08:b0:b72:a5bd:c585 with SMTP id a640c23a62f3a-b7671732667mr3734434066b.46.1764430900049; Sat, 29 Nov 2025 07:41:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1764430900; cv=none; d=google.com; s=arc-20240605; b=k1jr8nr1RPRcdlOwMgNVdt0N+zc4F5HYkFi2qh8UDFHvrX+wSdESjA7H5gUUMWW5MA 5VzTrPC0QycEO7bjqa8mIGw70cqZUAGFSNsUQBPcLsTyQxh/dtqG+/MYdicH+E9olsRX wLD6DgfiuXbXFY0c5Vhx0KJu1eJmkfeBEcRzDk2QMKLWPBnivElG44yy3/mQGU+y8IsU dJZFetV3DC4k6iQAWyPnLWgKLQZDDU8jvkcFwqj5rzLCWP0mZIULhdmUocW18wJuO9vW VvRhF4WQjROed+JOqpdyGMBq2909alqHEbpA1eYXXgi8chyzI0pev7hmXNbecmuOJAZh 1TXQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=DWIVtgeMoJRxaOa0Qi/ZLvO1mRh96ZJUVNWxzq0VGVs=; fh=zfrgopOiIZUyW/QOQMW3tlf+B0T0p2fpIoXRbxgb3Y8=; b=WCPpdNhpwUwLiMdxuz5Xo2sJp7l5c3LgGHn2fA8hEuC101GiPSjLZQBEeUaOKoOYqD pd52RlYwVofqt2rehEa+a51A7KX8G94+vL05K7zVLWgVgKqZ3gf7hp3/jkKKTl7Bi+qk 3qHxPuF/QYFZ7FVvSXASXGrjXob5W8gY+Et5LPuUgB0roOpDSO6xdk/IzzLXhoZ0LeTX CgCOZBTeVXLhbRMYgwB1/emF1d8Tp9+evs57QU/XmCg+jCZCjisz6yOlc7yYwXDDgAyv bbTp6h3YPwwHGsu2jZgRcLVg/OOSrUV/QZBJl6VBj1QYl6PITQX6tG0DwX94Jowon0IO Nwzg==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@q32-com.20230601.gappssmtp.com header.s=20230601 header.b=ypegZeyl; spf=pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::62e as permitted sender) smtp.mailfrom=earonesty@gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com. [2a00:1450:4864:20::62e]) by gmr-mx.google.com with ESMTPS id a640c23a62f3a-b76f5a43a87si12766766b.4.2025.11.29.07.41.40 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 29 Nov 2025 07:41:40 -0800 (PST) Received-SPF: pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::62e as permitted sender) client-ip=2a00:1450:4864:20::62e; Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-b7697e8b01aso555840466b.2 for ; Sat, 29 Nov 2025 07:41:40 -0800 (PST) X-Gm-Gg: ASbGncsoKgBMtuHxUWTU61msZBuRd/dfJajZWzvw4k19gipui+SQRJBiGqvnN+1qi+M InzYxZVH2aDYGyDYbWjdSEs8ivco86G1gYlwe71j08+0Rg6ySpFWToZRdOiP/5dwOsuloi5GfLg 0FZeow6eXiAu9K7eYj94QF2yXv9JqHbaxbb2XHL61eIjzHEMVfIhv7tfSidmGmwTgl7zYS1Qdtt LUsYkUkzxyvnRGf551AMMbdUKbL6bNBdxbnZsQCQIJ75G83QWYpwQmW0WwiMzyC4LwdNt1zUbcO IGMwrNCsxuP3JxfM+Bb6TFM7M9Y8wQ== X-Received: by 2002:a17:907:2da8:b0:b73:74d6:d360 with SMTP id a640c23a62f3a-b7671731884mr3550978366b.40.1764430899264; Sat, 29 Nov 2025 07:41:39 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Erik Aronesty Date: Sat, 29 Nov 2025 07:41:21 -0800 X-Gm-Features: AWmQ_bkFSLM5d1ff2vtiCxGewUoM49vV1C22AOlNpUHyu0QEexD-pA3_Mu11OZA Message-ID: Subject: Re: [bitcoindev] A safe way to remove objectionable content from the blockchain To: "waxwing/ AdamISZ" Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="000000000000fb41740644bd94ff" X-Original-Sender: erik@q32.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@q32-com.20230601.gappssmtp.com header.s=20230601 header.b=ypegZeyl; spf=pass (google.com: domain of earonesty@gmail.com designates 2a00:1450:4864:20::62e as permitted sender) smtp.mailfrom=earonesty@gmail.com; dara=pass header.i=@googlegroups.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.7 (/) --000000000000fb41740644bd94ff Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable You can stop arbitrary data encoding in public keys by requiring every key to be the **unique hash-to-curve output** of a publicly verifiable BLS root signature, rather than a user-chosen point on secp256k1. Because a BLS signature is checkable via a pairing equation, verifiers can confirm that each public key was deterministically forced by the root certificate and not selected to embed arbitrary bits. Under this construction, public keys become outputs of a constrained randomness beacon rather than an open steganographic channel. In practice, the system fixes a BLS12-381 public key `PK_root` and a one-time BLS signature `=CF=83 =3D Sign_root(S)`. Any allowed secp256k1 key= is then defined as `P_i =3D HashToCurve_secp256k1(=CF=83 || i)`, where `i` is = an arbitrary index and the hash-to-curve map is a standard indifferentiable encoding (e.g., IETF RFC 9380). Verifiers check the pairing equation `e(=CF= =83, g) =3D e(H(S), PK_root)` once, and thereafter reject any public key whose curve point does not equal the canonical hash-to-curve output for some disclosed index `i`. Because the signer never chooses curve points=E2=80=94= and because hash-to-curve eliminates degrees of freedom=E2=80=94no entropy rema= ins to smuggle bits into the key, satisfying the same non-malleability criteria used in anti-steganographic constructions. This =E2=80=9Cforced randomness=E2=80=9D model parallels techniques in the = literature on steganographic resistance and extractable commitments, particularly Hopper=E2=80=93Langford=E2=80=93von Ahn=E2=80=99s work on *provably secure = steganography* and Bellare=E2=80=93Ristenpart=E2=80=93Tessaro=E2=80=99s analyses of *channel i= ndistinguishability* in public-key spaces. The underlying idea is identical: eliminate sender choice over high-entropy objects so the objects cannot become covert storage. On Sat, Nov 29, 2025, 5:57=E2=80=AFAM waxwing/ AdamISZ = wrote: > Hi Peter, list, > > Interesting! > > One thought that springs to mind: attempts to ameliorate IBD 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 ZK property for > 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 > requires more data/bandwidth probably loses out to versions that have les= s > data/bandwidth. Hmm. > > It seems to demonstrate, to me, that some kind of "data carrying" is > required in the "state" (cf the "history"). Ironically recent discussion > (see 'On (in)ability 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 that (see > typical rollup design) data carrying in state can do the job that you are > (correctly) insisting, must be done. > (And the corollary: "harmful data on the blockchain" is a wrong mental > model and should be abandoned, irrespective of architecture.) > > Aside from your *main* concept here, I think the idea that HTLCs require > *proof* of publication is wrong. What they require is publication. A > wronged channel party needs to read the preimage, not have proof that it > can be read. Take as contrast the opentimestamps model, where having proo= f > that something was published, is the main functionality offered/required.= I > suppose there is another 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* > published. > > Cheers, > AdamISZ/waxwing > > On Saturday, November 29, 2025 at 8:32:21=E2=80=AFAM UTC-3 Peter Todd wro= te: > >> 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. >> > >> > There is a solution that does everything you want it and more, ZKPs. >> > >> > ZKP (Zero Knowledge Proofs) can prove that some data X hashes to some >> hash >> > output Y while keeping the actual value X secret. Thus, everyone can b= e >> > convinced that H(X) =3D Y even if X is deleted and no one knows what t= he >> > value X was. >> > >> > 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 >> 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 numbe= r >> of >> > transactions or bytes compressed. This approach does not require any >> > changes to Bitcoin and you could implement a Bitcoin full node today >> that >> > supports this. >> > >> > We have a solution to solve the problem of harmful data on the >> blockchain >> > since 2017. It just requires time, money and motivated people to work >> on it. >> >> Rather than being a solution, the technology behind Zerosync is a >> potential >> threat to Bitcoin. The problem is that Bitcoin fundamentally requires >> proof-of-publication to be decentralized and censorship resistant; a >> 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 >> propagated >> in a form suitable for creating new blocks. ZKP/Zerosync makes it >> possible 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 o= n >> top >> of because they do not contain the UTXO set data necessary to mine a new >> block. >> >> Why do miners have an incentive to distribute the blocks they find? >> Ultimately >> 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 t= o >> 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 >> pre-image >> in the Bitcoin chain, allowing the other party relying on the HTLC to >> recover >> the pre-image. Again, ZKP/Zerosync weakens this security, as the validit= y >> 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 >> entirely. >> We need a consensus protocol where the only way to fully validate a bloc= k >> is to >> actually have the entire block contents. >> >> As for "harmful data", that is a challenge to be solved >> legally/politically. >> >> -- >> https://petertodd.org 'peter'[:-1]@petertodd.org >> > -- > 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 > email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/f5cf7fb8-61ce-437b-b26b-241d= 47b3fcb5n%40googlegroups.com > > . > --=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/= CAJowKg%2B4DjP-c%3D0MJbZC1cTRU_RisRr7-dS%3Di7c4ir4fSngvXw%40mail.gmail.com. --000000000000fb41740644bd94ff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You can stop arbitrary data encoding in public keys by re= quiring every key to be the **unique hash-to-curve output** of a publicly v= erifiable BLS root signature, rather than a user-chosen point on secp256k1.= =C2=A0

Because a BLS signature= is checkable via a pairing equation, verifiers can confirm that each publi= c key was deterministically forced by the root certificate and not selected= to embed arbitrary bits. Under this construction, public keys become outpu= ts of a constrained randomness beacon rather than an open steganographic ch= annel.

In practice, the = system fixes a BLS12-381 public key `PK_root` and a one-time BLS signature = `=CF=83 =3D Sign_root(S)`. Any allowed secp256k1 key is then defined as `P_= i =3D HashToCurve_secp256k1(=CF=83 || i)`, where `i` is an arbitrary index = and the hash-to-curve map is a standard indifferentiable encoding (e.g., IE= TF RFC 9380). Verifiers check the pairing equation `e(=CF=83, g) =3D e(H(S)= , PK_root)` once, and thereafter reject any public key whose curve point do= es not equal the canonical hash-to-curve output for some disclosed index `i= `. Because the signer never chooses curve points=E2=80=94and because hash-t= o-curve eliminates degrees of freedom=E2=80=94no entropy remains to smuggle= bits into the key, satisfying the same non-malleability criteria used in a= nti-steganographic constructions.

This =E2=80=9Cforced randomness=E2=80=9D model parallels techniqu= es in the literature on steganographic resistance and extractable commitmen= ts, particularly Hopper=E2=80=93Langford=E2=80=93von Ahn=E2=80=99s work on = *provably secure steganography* and Bellare=E2=80=93Ristenpart=E2=80=93Tess= aro=E2=80=99s analyses of *channel indistinguishability* in public-key spac= es.=C2=A0

The underlying= idea is identical: eliminate sender choice over high-entropy objects so th= e objects cannot become covert storage.


On Sat, Nov 29, 2025, 5:57=E2=80=AFAM waxwing/ AdamISZ = <ekaggata@gmail.com> wrote:=
Hi Peter, list,
Interesting!

One thought that springs = to mind: attempts to ameliorate IBD with ZKP should not forget one thing: w= hat we actually want here is succinctness, and not so much ZK. Think SNARK = instead of ZkSNARK.
Which is important; without the requirement f= or an actual ZK property for the protocol, you can have it have attached wi= tness that is not secret.

Then a counter-thought s= trikes, that any version of these protocols that requires more data/bandwid= th probably loses out to versions that have less data/bandwidth. Hmm.
=

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

I do think, long term that ZKP over history is correct= , and that (see typical rollup design) data carrying in state can do the jo= b that you are (correctly) insisting, must be done.
(And the coro= llary: "harmful data on the blockchain" is a wrong mental model a= nd should be abandoned, irrespective of architecture.)

=
Aside from your *main* concept here, I think the idea that HTLCs requi= re *proof* of publication is wrong. What they require is publication. A wro= nged channel party needs to read the preimage, not have proof that it can b= e read. Take as contrast the opentimestamps model, where having proof that = something was published, is the main functionality offered/required. I supp= ose there is another 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:
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, 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 bitcoindev+unsubscribe@googlegroups.com.=
To view this discussion visit h= ttps://groups.google.com/d/msgid/bitcoindev/f5cf7fb8-61ce-437b-b26b-241d47b= 3fcb5n%40googlegroups.com.

--
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.co= m/d/msgid/bitcoindev/CAJowKg%2B4DjP-c%3D0MJbZC1cTRU_RisRr7-dS%3Di7c4ir4fSng= vXw%40mail.gmail.com.
--000000000000fb41740644bd94ff--