From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 29 Nov 2025 08:15:21 -0800 Received: from mail-oi1-f187.google.com ([209.85.167.187]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vPNbT-0007bp-QV for bitcoindev@gnusha.org; Sat, 29 Nov 2025 08:15:20 -0800 Received: by mail-oi1-f187.google.com with SMTP id 5614622812f47-45322138f81sf1904006b6e.0 for ; Sat, 29 Nov 2025 08:15:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1764432914; x=1765037714; 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=l5E2rkxlKgtS5aI2ehIol3AbZpaAx4EtgpUnnR5kWNM=; b=GzEzC3qzYEQ90l0V+dZlwmBEKs0gjPwiET4PCbmhD99J7tSre+oMnO0KNZSVvRLXbi TFfAC/JAp4X88u0OOm7Mc7Ok7GS+657ZL8GR7t50sanmPxj9lEoFHOyPHNkoM6WItsEC TCDum4E/5HAH1PfxBG3crXvErpT8NOP7xqXK2aE20etAAzfmZqEREyx+CT/MWlR5JF/3 CTPuU1SJ2rQdfq0bLofT7ov6xQRssDLKQQgjxEfb2x/iF4CM+/YunGPW67jau2dnLniF /ZxV2JKtI91RwG+z9SGgyv4KwkJhzAFANCMGaEaTeRR5LbUk5ZdLSpjGW4SidRYxhAcv ibSQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764432914; x=1765037714; 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=l5E2rkxlKgtS5aI2ehIol3AbZpaAx4EtgpUnnR5kWNM=; b=eCQu9/RUnvtk7JR/sGKGv8gu+fOn4ppk5w+eo6Y1K/++YxMMHBk0RsKSKJ9uU83mju PlqWBR8zn6W+UpKTulvVMG/RSsbueH9uW6J1cBnW9lIR8v4/CR4zeHyUy/qP7S3MHP1A NeM4YWaBvnbteCnIK4lJlAAV164jXDnqoCGcImXInxV0U/bqq0rcEaKAGlTdGp1VZxtk cqGYpTZ5tYYDluFyh7bFirN3p324QZgvn2PguDXPYBfFc9DKmvD/w9ONMTwX9xr9R/yD LGFBlUX2CqIbQCvVwauJCpoj3hnvpiBTQguhWt2bO1p9aZEUScNn7x4FYgXvsV0cXy/I kkdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764432914; x=1765037714; 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=l5E2rkxlKgtS5aI2ehIol3AbZpaAx4EtgpUnnR5kWNM=; b=shk5xfnZhdgy/1JzBDvgInKawaiS+Scd1YKW7ldfIRMEUO52oqAKAsjDR8dVzbdKLo N+HoG1UlQO2Jxfx+cy4U819Tn/Q1DTL0zRgMYmn+mU2DxuvL6jQ+/XF5v8quVV6XmC3a WJjz/n5j1I51odtWC2Xnt/kRtzJYE+kUYLo7pwkSoRE+exp0PzGZ+0qZCNQhrSYiu0KK t73aPsnIHWHjTjF6NoyIQCzToV1wEIPZYEpDWFnr5efiyVTIyyTRHjplfIdWt5H5cYC2 SP2XJAy6h/+dU7UFmHjZ02hbzPUIB/qRRgw20FeNXQwA8c7beVPeYltVeEjH/2tTFD0d 6sdQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCUVAnTgBOs/eV/diVP4nr83qNj1zJX3CVMHZe9htKiawwGYwikc8vTtvL++YrPGMXg9Y9QzY+RlpVFP@gnusha.org X-Gm-Message-State: AOJu0Yw+CqHL/0kquFQZoCDc8zHNkN6ztmsR8mpYf0AX+PvHWD7tcqo8 1CYdNieQCAXqiqPySs9ZsITrxaxFCNmmEMfQTp0zVBzriGgGENZnLr7e X-Google-Smtp-Source: AGHT+IFEP9lrYwfCa8LZsgiTc7YszEuD2tgvSSH4Y9LH0bIqsPyVve09DvGJH1naXNcmk5tsdxT7Ew== X-Received: by 2002:a05:6808:1526:b0:44d:be91:afe9 with SMTP id 5614622812f47-45101e935aamr14490640b6e.27.1764432913442; Sat, 29 Nov 2025 08:15:13 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+Zz3o8/YgsGnrTBxnhWtptAagHXwYkGSh5L34XKssmfNQ==" Received: by 2002:a05:6871:81d9:10b0:331:5ba5:afd3 with SMTP id 586e51a60fabf-3f0d285af77ls1360569fac.1.-pod-prod-07-us; Sat, 29 Nov 2025 08:15:09 -0800 (PST) X-Received: by 2002:a05:6808:150a:b0:450:46e:9ceb with SMTP id 5614622812f47-4514e7fde6dmr8534242b6e.55.1764432909795; Sat, 29 Nov 2025 08:15:09 -0800 (PST) Received: by 2002:a05:690c:2d86:b0:78a:986f:9439 with SMTP id 00721157ae682-78bdb636a71ms7b3; Sat, 29 Nov 2025 07:56:51 -0800 (PST) X-Received: by 2002:a05:690e:23cb:b0:63f:9ff9:1493 with SMTP id 956f58d0204a3-643292228f5mr12784728d50.2.1764431810611; Sat, 29 Nov 2025 07:56:50 -0800 (PST) Date: Sat, 29 Nov 2025 07:56:50 -0800 (PST) From: waxwing/ AdamISZ To: Bitcoin Development Mailing List Message-Id: <1d1c5d9c-9b36-4e4b-930c-d23b2f562052n@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_393150_1482153993.1764431810029" 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_393150_1482153993.1764431810029 Content-Type: multipart/alternative; boundary="----=_Part_393151_1633913412.1764431810029" ------=_Part_393151_1633913412.1764431810029 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Erik, > You can stop arbitrary data encoding in public keys by requiring every=20 key to be the **unique hash-to-curve output** of a publicly verifiable BLS= =20 root signature, rather than a user-chosen point on secp256k1.=20 Indeed, absolutely correct (afaik!), I had recently been discussing this a= =20 bit with Lloyd Fournier on nostr. I think at a theoretical level this is a= =20 very important observation, but at a practical level not so much. It's also= =20 worth noting that something like RSA FDH or hash based signatures, since=20 they're deterministic (think "no nonce" and no technical ZK property) could= =20 technically do the same thing, but BLS is far and away better than those. Theoretical not practical: I think there's no way such a thing would happen= =20 on bitcoin (IMO! could be wrong!) because it's an absolutely huge change to= =20 the crypto without improving quantum resistance (performance issues are I= =20 guess an open question, considering batching properties vs raw performance= =20 of a single pairing being bad). And the other reason: no point going this= =20 far without attempting to patch *every* hole that allows data that is not= =20 trivial. You could argue these holes are trivial: amount data, locktimes=20 (both nLockTime and nSequence), in/out sequencing not being deterministic,= =20 and grinding curve points. The obviously much more relevant and non-trivial= =20 issue is Script, generally, and sort of peripheral to script stuff like=20 control block in taproot etc. Since you'd have to "address" (that is to=20 say, gut) Bitcoin's scripting before these other things like deterministic= =20 signatures become relevant, it does seem all very theoretical, if=20 interesting. I guess this would have been better in the "On (in)ability to embed data in= =20 Schnorr" thread but w/e it's all kind of connected I guess! Cheers, AdamISZ/waxwing On Saturday, November 29, 2025 at 12:43:56=E2=80=AFPM UTC-3 Erik Aronesty w= rote: > You can stop arbitrary data encoding in public keys by requiring every ke= y=20 > to be the **unique hash-to-curve output** of a publicly verifiable BLS ro= ot=20 > signature, rather than a user-chosen point on secp256k1.=20 > > Because a BLS signature is checkable via a pairing equation, verifiers ca= n=20 > confirm that each public key was deterministically forced by the root=20 > certificate and not selected to embed arbitrary bits. Under this=20 > construction, public keys become outputs of a constrained randomness beac= on=20 > rather than an open steganographic channel. > > In practice, the system fixes a BLS12-381 public key `PK_root` and a=20 > one-time BLS signature `=CF=83 =3D Sign_root(S)`. Any allowed secp256k1 k= ey is=20 > then defined as `P_i =3D HashToCurve_secp256k1(=CF=83 || i)`, where `i` i= s an=20 > arbitrary index and the hash-to-curve map is a standard indifferentiable= =20 > encoding (e.g., IETF RFC 9380). Verifiers check the pairing equation `e(= =CF=83,=20 > g) =3D e(H(S), PK_root)` once, and thereafter reject any public key whose= =20 > curve point does not equal the canonical hash-to-curve output for some=20 > disclosed index `i`. Because the signer never chooses curve points=E2=80= =94and=20 > because hash-to-curve eliminates degrees of freedom=E2=80=94no entropy re= mains to=20 > smuggle bits into the key, satisfying the same non-malleability criteria= =20 > used in anti-steganographic constructions. > > This =E2=80=9Cforced randomness=E2=80=9D model parallels techniques in th= e literature on=20 > steganographic resistance and extractable commitments, particularly=20 > Hopper=E2=80=93Langford=E2=80=93von Ahn=E2=80=99s work on *provably secur= e steganography* and=20 > Bellare=E2=80=93Ristenpart=E2=80=93Tessaro=E2=80=99s analyses of *channel= indistinguishability* in=20 > public-key spaces.=20 > > The underlying idea is identical: eliminate sender choice over=20 > 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=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 fo= r=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 le= ss=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 o= f=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 ar= e=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 pro= of=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 wr= ote: >> >>> On Thu, Nov 20, 2025 at 04:21:33PM -0500, Ethan Heilman wrote:=20 >>> > I'm not convinced your hash function approach fully does what you wan= t=20 >>> it=20 >>> > to, although it does seem doable with some additional constraints.=20 >>> >=20 >>> > There is a solution that does everything you want it and more, ZKPs.= =20 >>> >=20 >>> > ZKP (Zero Knowledge Proofs) can prove that some data X hashes to some= =20 >>> hash=20 >>> > output Y while keeping the actual value X secret. Thus, everyone can= =20 >>> be=20 >>> > convinced that H(X) =3D Y even if X is deleted and no one knows what = the=20 >>> > value X was.=20 >>> >=20 >>> > Even more exciting, ZKPs can prove the correctness and validity of th= e=20 >>> > entire Bitcoin blockchain. Thus storing old transactions is=20 >>> > no longer needed to convince others that the chain is correct. This= =20 >>> would=20 >>> > remove any harmful data. Zerosync in 2017 compressed Bitcoin's=20 >>> blockchain=20 >>> > into a 800 KB proof [0] which is constant size regardless of the=20 >>> number of=20 >>> > transactions or bytes compressed. This approach does not require any= =20 >>> > changes to Bitcoin and you could implement a Bitcoin full node today= =20 >>> that=20 >>> > supports this.=20 >>> >=20 >>> > We have a solution to solve the problem of harmful data on the=20 >>> blockchain=20 >>> > since 2017. It just requires time, money and motivated people to work= =20 >>> on it.=20 >>> >>> Rather than being a solution, the technology behind Zerosync is a=20 >>> potential=20 >>> threat to Bitcoin. The problem is that Bitcoin fundamentally requires= =20 >>> proof-of-publication to be decentralized and censorship resistant; a=20 >>> related=20 >>> problem is that HTLCs (and thus Lightning) fundamentally requires=20 >>> proof-of-publication to work at all.=20 >>> >>> For Bitcoin mining to remain decentralized, blocks need to be widely=20 >>> propagated=20 >>> in a form suitable for creating new blocks. ZKP/Zerosync makes it=20 >>> possible to=20 >>> prove that a block hash and all prior blocks follow the protocol rules= =20 >>> and were=20 >>> thus valid. However, valid block hashes alone are insufficient to mine= =20 >>> on top=20 >>> of because they do not contain the UTXO set data necessary to mine a ne= w=20 >>> block.=20 >>> >>> Why do miners have an incentive to distribute the blocks they find?=20 >>> Ultimately=20 >>> because doing so is necessary for the coins they mined to be valuable.= =20 >>> But if=20 >>> full nodes can be convinced of the validity of coins without full block= =20 >>> contents --- thus allowing those coins to be sold --- that weakens the= =20 >>> incentives to distribute block data in a form that allows other miners= =20 >>> to mine.=20 >>> >>> >>> With regard to HTLCs/Lightning, HTLCs rely on a proof-of-publication to= =20 >>> be=20 >>> secure: for the HTLC to be redeemed, the redeemer *must* publish the=20 >>> pre-image=20 >>> in the Bitcoin chain, allowing the other party relying on the HTLC to= =20 >>> recover=20 >>> the pre-image. Again, ZKP/Zerosync weakens this security, as the=20 >>> validity of=20 >>> the transaction spending the HTLC can be proven without actually making= =20 >>> the=20 >>> pre-image available.=20 >>> >>> >>> Rather than presenting ZKP/Zerosync as a solution to the "harmful data"= =20 >>> problem, we should in fact be researching ways to defeat ZKP/Zerosync= =20 >>> entirely.=20 >>> We need a consensus protocol where the only way to fully validate a=20 >>> block is to=20 >>> actually have the entire block contents.=20 >>> >>> As for "harmful data", that is a challenge to be solved=20 >>> legally/politically.=20 >>> >>> --=20 >>> https://petertodd.org 'peter'[:-1]@petertodd.org=20 >>> >> --=20 >> > You received this message because you are subscribed to the Google Groups= =20 >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n=20 >> email to bitcoindev+...@googlegroups.com. >> > To view this discussion visit=20 >> https://groups.google.com/d/msgid/bitcoindev/f5cf7fb8-61ce-437b-b26b-241= d47b3fcb5n%40googlegroups.com=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/= 1d1c5d9c-9b36-4e4b-930c-d23b2f562052n%40googlegroups.com. ------=_Part_393151_1633913412.1764431810029 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Erik,

> You can stop arbitrary data e= ncoding in public keys by requiring every=20 key to be the **unique hash-to-curve output** of a publicly verifiable=20 BLS root signature, rather than a user-chosen point on secp256k1.=C2=A0

Indeed, absolutely correct (afaik!), I had recently= been discussing this a bit with Lloyd Fournier on nostr. I think at a theo= retical level this is a very important observation, but at a practical leve= l not so much. It's also worth noting that something like RSA FDH or hash b= ased signatures, since they're deterministic (think "no nonce" and no techn= ical ZK property) could technically do the same thing, but BLS is far and a= way better than those.

Theoretical not practical= : I think there's no way such a thing would happen on bitcoin (IMO! could b= e wrong!) because it's an absolutely huge change to the crypto without impr= oving quantum resistance (performance issues are I guess an open question, = considering batching properties vs raw performance of a single pairing bein= g bad). And the other reason: no point going this far without attempting to= patch *every* hole that allows data that is not trivial. You could argue t= hese holes are trivial: amount data, locktimes (both nLockTime and nSequenc= e), in/out sequencing not being deterministic, and grinding curve points. T= he obviously much more relevant and non-trivial issue is Script, generally,= and sort of peripheral to script stuff like control block in taproot etc. = Since you'd have to "address" (that is to say, gut) Bitcoin's scripting bef= ore these other things like deterministic signatures become relevant, it do= es seem all very theoretical, if interesting.

I = guess this would have been better in the "On (in)ability to embed data in S= chnorr" thread but w/e it's all kind of connected I guess!

=
Cheers,
AdamISZ/waxwing

On Saturday, November 29, 20= 25 at 12:43:56=E2=80=AFPM UTC-3 Erik Aronesty wrote:
You can stop arbi= trary data encoding in public keys by requiring every key to be the **uniqu= e hash-to-curve output** of a publicly verifiable BLS root signature, rathe= r than a user-chosen point on secp256k1.=C2=A0

<= div dir=3D"auto">Because a BLS signature is checkable via a pairing equatio= n, verifiers can confirm that each public key was deterministically forced = by the root certificate and not selected to embed arbitrary bits. Under thi= s construction, public keys become outputs of a constrained randomness beac= on rather than an open steganographic channel.

<= /div>
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 allo= wed 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 stan= dard indifferentiable encoding (e.g., IETF RFC 9380). Verifiers check the p= airing equation `e(=CF=83, g) =3D e(H(S), PK_root)` once, and thereafter re= ject 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=94and because hash-to-curve eliminates degrees of freed= om=E2=80=94no entropy remains to smuggle bits into the key, satisfying the = same non-malleability criteria used in anti-steganographic constructions.

This =E2=80=9Cforced rand= omness=E2=80=9D model parallels techniques in the literature on steganograp= hic resistance and extractable commitments, particularly Hopper=E2=80=93Lan= gford=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 = indistinguishability* in public-key spaces.=C2=A0
The underlying idea is identical: eliminate sende= r choice over high-entropy objects so the objects cannot become covert stor= age.


=
On S= at, Nov 29, 2025, 5:57=E2=80=AFAM waxwing/ AdamISZ <ekag...@gmail.com> wrote:
Hi Peter, list,<= /div>

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 hav= e attached witness that is not secret.

Then a coun= ter-thought strikes, that any version of these protocols that requires more= data/bandwidth probably loses out to versions that have less data/bandwidt= h. Hmm.

=C2=A0It 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 "d= iscussions" on the internet about filtering and spam...) has just re-e= mphasized that the utxo set can inevitably carry data (I guess that's o= bvious).

I do think, long term that ZKP over histo= ry 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 m= ental model and should be abandoned, irrespective of architecture.)

Aside from your *main* concept here, I think the idea tha= t HTLCs require *proof* of publication is wrong. What they require is publi= cation. A wronged channel party needs to read the preimage, not have proof = that it can be read. Take as contrast the opentimestamps model, where havin= g proof that something was published, is the main functionality offered/req= uired. I suppose there is another way to say it: the channel counterparty n= eeds "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= 9;[:-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+..= .@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/f5cf7fb8-61ce-437b-b26b-= 241d47b3fcb5n%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.com/d/msgid/bitcoind= ev/1d1c5d9c-9b36-4e4b-930c-d23b2f562052n%40googlegroups.com.
------=_Part_393151_1633913412.1764431810029-- ------=_Part_393150_1482153993.1764431810029--