From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 29 Nov 2025 10:56:08 -0800 Received: from mail-oa1-f61.google.com ([209.85.160.61]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vPQ74-0000Uz-N7 for bitcoindev@gnusha.org; Sat, 29 Nov 2025 10:56:08 -0800 Received: by mail-oa1-f61.google.com with SMTP id 586e51a60fabf-3ed141de56asf2646855fac.2 for ; Sat, 29 Nov 2025 10:56:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1764442561; x=1765047361; 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=MZxU7CRsg+UeMBFqixRlPH2JXl2URjPVghhrgnL0ACc=; b=OohDV3nWdYA34TmK9iCADHvAekauY9ehtU/sas5kA4Qra8lNQnVJcAijCCUpZZsQ+b KZG27wG4ySLB5hbfV4JhOzD8XUmuhmqz9t037axYpS2Yk2afnAzjlpqtzj4uTFmliGxw NwVvb4/9VJPoZnfc63vGRMG8mTyjMo3PYCZKdUlCfh1/wdTLKHc7raVw4ej1jNact1KL 9qqwQwpV8RdBze9I10zWSlGdT/KTLC08k7MeQkavS6faizVczw7HJUgw1YVFlKuZ5ezI N29p6YACe3vTxxxFtOZcJ5yQEzi5rSz2rJiadjdAbrKnikxkHUCc4Os1ZaaJIhY3Puzi I9gQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764442561; x=1765047361; 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=MZxU7CRsg+UeMBFqixRlPH2JXl2URjPVghhrgnL0ACc=; b=KCBa8VTn0j1reVDb0IpX6v1+FWbZC0llNzaOgQQjNn8k2b1mjnNPTwqyJlplxrn8gn u35NmWM/TX46W9SbEJK+J4Fp+2txwQ5nwdeDfb4KraN386m9PrqBQkFKnWoV9ocUJax2 pRSQfH+esIviYswb/xUA2pI/jzgReos/gq0lnvTRcfwgz8w7mUL09PWL+lnIfef7pIGI WJ65QB5HUE5M7fwbfu2AKnPbFQt22ksUy9Oy7fUmvZ1heQYp4n9fU/OSpOQP8G0gAi6R LgLzSazABDaiogZjImevLgr1IdGMqi1KP+4sWvQ2DWmy1Azb1fdhsGKOUQwgGVSxM1h0 XuCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764442561; x=1765047361; 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=MZxU7CRsg+UeMBFqixRlPH2JXl2URjPVghhrgnL0ACc=; b=XBjoOR8YXHmbfG/WKJdp8lvAPUx6jfP/gYCA+AfI6CSqo5xQj2EQYoruHKCs5A6rU5 os3RSy3Vc9lGXYVOacd6y1m7wleTfrhxtTEparulO9a6rbBoGunqta8MU0PHQq1OOpsR uvTYylRX2GqK2Jtq1RsT4lZBacJDKnzGHS4tCBMqLM0cffTglODHW+ieiRbHlb2cEsfg cZ3PyIWH8niOwNJe3v4G5FL8wwIQ/DMNqJCV8NSQ3rPiVdyp6MWnVTeFGZ7FWbmxw7Ud sOtdDJ9dCZRtU/qha0mNS5oxFQYep/RQMcnAxJjT7OkOhly70jZhRs6HpYxTpaJWVVu1 1cyg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCUguRBGrLmZGBQSWeDO3mSweDn59547b2Tlv690cUwLtnLC3hRzM0l/d9NokW/oGEqlGOS2ef6XTHe0@gnusha.org X-Gm-Message-State: AOJu0YyLeQHsBj4YfmZ38HcWS+S9w6UkYHChkbHjpfUjKTW+GXcg7Rbv dbr9TOscgdVoxcgzsmZqKn+8Mre0gU1aqYhAMC9yPQq8fRq/79B+yaxU X-Google-Smtp-Source: AGHT+IEF3gIFkS3uhCMdQrmQc/UaRHuNM4JuIKNENuRDdewhWNb9tuOlJ9qMb0bdNFrxtqe4qea7ng== X-Received: by 2002:a05:6870:d1c2:b0:3e7:eba1:fdd with SMTP id 586e51a60fabf-3ed1fdb8918mr9098991fac.15.1764442560474; Sat, 29 Nov 2025 10:56:00 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+Zl0jkTk3hrZrvaJXJtw5G69yBnawvSCc/MoZdtOSTRzQ==" Received: by 2002:a05:6870:12d8:b0:3ec:5edf:7cfc with SMTP id 586e51a60fabf-3f0d20ddfdals1263679fac.1.-pod-prod-04-us; Sat, 29 Nov 2025 10:55:55 -0800 (PST) X-Received: by 2002:a05:6808:678b:b0:44d:aa6b:a58b with SMTP id 5614622812f47-4511598072bmr12926360b6e.23.1764442555741; Sat, 29 Nov 2025 10:55:55 -0800 (PST) Received: by 2002:a81:fb03:0:b0:786:8d90:70d8 with SMTP id 00721157ae682-78ac3365063ms7b3; Sat, 29 Nov 2025 10:52:53 -0800 (PST) X-Received: by 2002:a53:acdc:0:20b0:641:f5bc:698b with SMTP id 956f58d0204a3-64302b1d8acmr20911327d50.71.1764442372697; Sat, 29 Nov 2025 10:52:52 -0800 (PST) Date: Sat, 29 Nov 2025 10:52:52 -0800 (PST) From: waxwing/ AdamISZ To: Bitcoin Development Mailing List Message-Id: <03f19c1a-ef1b-40c9-9864-ce84e6b5ddbdn@googlegroups.com> In-Reply-To: References: <1d1c5d9c-9b36-4e4b-930c-d23b2f562052n@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_409346_572659653.1764442372290" 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_409346_572659653.1764442372290 Content-Type: multipart/alternative; boundary="----=_Part_409347_958354913.1764442372290" ------=_Part_409347_958354913.1764442372290 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Erik, > 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 key= is=20 then defined as `P_i =3D HashToCurve_secp256k1(=CF=83 || i)`, where `i` is = 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=94= and=20 because hash-to-curve eliminates degrees of freedom=E2=80=94no entropy rema= ins to=20 smuggle bits into the key, satisfying the same non-malleability criteria=20 used in anti-steganographic constructions. Oh, I confess when you said "BLS" I didn't read the details and then just= =20 went off on the assumption you were talking about a replacement of secp=20 with a BLS curve and then outputs being (BLS pubkey, BLS sig) i.e. an=20 attached PoK of the key. But now I do actually read what you specifically= =20 meant, I realize I don't understand it: if the secp key is=20 Hash-to-curve(sigma, i) then you don't have the private key of that pubkey.= =20 How could that be used? I don't get it. Maybe it's because I don't know=20 what S is, in this scheme, or maybe not. Lloyd and I rejected the idea of still using secp but attaching a BLS sig= =20 to it. That feels unworkable (mapping keys across groups or w/e), you'd=20 need to just switch to a BLS curve entirely, I think. AdamISZ/waxwing On Saturday, November 29, 2025 at 3:16:34=E2=80=AFPM UTC-3 Greg Maxwell wro= te: > You cannot perform pairing on secp256k1 as the DDH is hard in that group,= =20 > so no BLS signature. You may find that you make fewer technical errors i= f=20 > you refrain from misrepresenting other people's ideas as your own origina= l=20 > work. > > > On Sat, Nov 29, 2025 at 5:17=E2=80=AFPM Erik Aronesty wro= te: > >> there is no fundamental change to the cryptography. The beacon proofs= =20 >> are only used for "proof of not spam". The proven Bitcoin key is the sa= me=20 >> secp256k1 key and spending is unchanged. uxto proofs are not terribly= =20 >> unreasonable given the cost of UTXOs=20 >> >> On Sat, Nov 29, 2025, 8:15=E2=80=AFAM waxwing/ AdamISZ wrote: >> >>> Hi Erik, >>> >>> > You can stop arbitrary data encoding in public keys by requiring ever= y=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 thi= s=20 >>> a bit with Lloyd Fournier on nostr. I think at a theoretical level this= is=20 >>> a very important observation, but at a practical level not so much. It'= s=20 >>> also worth noting that something like RSA FDH or hash based signatures,= =20 >>> since they're deterministic (think "no nonce" and no technical ZK prope= rty)=20 >>> could technically do the same thing, but BLS is far and away better tha= n=20 >>> those. >>> >>> Theoretical not practical: I think there's no way such a thing would=20 >>> happen on bitcoin (IMO! could be wrong!) because it's an absolutely hug= e=20 >>> change to the crypto without improving quantum resistance (performance= =20 >>> issues are I guess an open question, considering batching properties vs= raw=20 >>> performance of a single pairing being bad). And the other reason: no po= int=20 >>> going this far without attempting to patch *every* hole that allows dat= a=20 >>> that is not trivial. You could argue these holes are trivial: amount da= ta,=20 >>> locktimes (both nLockTime and nSequence), in/out sequencing not being= =20 >>> deterministic, and grinding curve points. The obviously much more relev= ant=20 >>> and non-trivial issue is Script, generally, and sort of peripheral to= =20 >>> script stuff like control block in taproot etc. Since you'd have to=20 >>> "address" (that is to say, gut) Bitcoin's scripting before these other= =20 >>> things like deterministic signatures become relevant, it does seem all = very=20 >>> theoretical, if interesting. >>> >>> I guess this would have been better in the "On (in)ability to embed dat= a=20 >>> in 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 Arones= ty wrote: >>> >>>> 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 >>>> >>>> Because a BLS signature is checkable via a pairing equation, verifiers= =20 >>>> can confirm that each public key was deterministically forced by the r= oot=20 >>>> certificate and not selected to embed arbitrary bits. Under this=20 >>>> construction, public keys become outputs of a constrained randomness b= eacon=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 secp256k= 1 key is=20 >>>> then defined as `P_i =3D HashToCurve_secp256k1(=CF=83 || i)`, where `i= ` is an=20 >>>> arbitrary index and the hash-to-curve map is a standard indifferentiab= le=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 wh= ose=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= remains to=20 >>>> smuggle bits into the key, satisfying the same non-malleability criter= ia=20 >>>> used in anti-steganographic constructions. >>>> >>>> This =E2=80=9Cforced randomness=E2=80=9D model parallels techniques in= the literature=20 >>>> on steganographic resistance and extractable commitments, particularly= =20 >>>> Hopper=E2=80=93Langford=E2=80=93von Ahn=E2=80=99s work on *provably se= cure steganography* and=20 >>>> Bellare=E2=80=93Ristenpart=E2=80=93Tessaro=E2=80=99s analyses of *chan= nel 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 =20 >>>> 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 succinctne= ss,=20 >>>>> and not so much ZK. Think SNARK instead of ZkSNARK. >>>>> Which is important; without the requirement for an actual ZK property= =20 >>>>> for the protocol, you can have it have attached witness that is not s= ecret. >>>>> >>>>> Then a counter-thought strikes, that any version of these protocols= =20 >>>>> that requires more data/bandwidth probably loses out to versions that= have=20 >>>>> less 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 discuss= ion=20 >>>>> (see 'On (in)ability to embed data into Schnorr' but yeah a googolple= x 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 th= at'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 menta= l=20 >>>>> model and should be abandoned, irrespective of architecture.) >>>>> >>>>> Aside from your *main* concept here, I think the idea that HTLCs=20 >>>>> require *proof* of publication is wrong. What they require is publica= tion.=20 >>>>> A wronged channel party needs to read the preimage, not have proof th= at it=20 >>>>> can be read. Take as contrast the opentimestamps model, where having = proof=20 >>>>> that something was published, is the main functionality offered/requi= red. I=20 >>>>> suppose there is another way to say it: the channel counterparty need= s=20 >>>>> "proof of future publication" in contract setup. That's fair enough b= ut=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:=20 >>>>>> > I'm not convinced your hash function approach fully does what you= =20 >>>>>> want 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,=20 >>>>>> ZKPs.=20 >>>>>> >=20 >>>>>> > ZKP (Zero Knowledge Proofs) can prove that some data X hashes to= =20 >>>>>> some hash=20 >>>>>> > output Y while keeping the actual value X secret. Thus, everyone= =20 >>>>>> can be=20 >>>>>> > convinced that H(X) =3D Y even if X is deleted and no one knows wh= at=20 >>>>>> the=20 >>>>>> > value X was.=20 >>>>>> >=20 >>>>>> > Even more exciting, ZKPs can prove the correctness and validity of= =20 >>>>>> the=20 >>>>>> > entire Bitcoin blockchain. Thus storing old transactions is=20 >>>>>> > no longer needed to convince others that the chain is correct. Thi= s=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= =20 >>>>>> any=20 >>>>>> > changes to Bitcoin and you could implement a Bitcoin full node=20 >>>>>> today 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= =20 >>>>>> work 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 require= s=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=20 >>>>>> rules and were=20 >>>>>> thus valid. However, valid block hashes alone are insufficient to=20 >>>>>> mine on top=20 >>>>>> of because they do not contain the UTXO set data necessary to mine a= =20 >>>>>> new 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=20 >>>>>> valuable. But if=20 >>>>>> full nodes can be convinced of the validity of coins without full=20 >>>>>> block=20 >>>>>> contents --- thus allowing those coins to be sold --- that weakens= =20 >>>>>> the=20 >>>>>> incentives to distribute block data in a form that allows other=20 >>>>>> miners to mine.=20 >>>>>> >>>>>> >>>>>> With regard to HTLCs/Lightning, HTLCs rely on a proof-of-publication= =20 >>>>>> to 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 t= o=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=20 >>>>>> making the=20 >>>>>> pre-image available.=20 >>>>>> >>>>>> >>>>>> Rather than presenting ZKP/Zerosync as a solution to the "harmful=20 >>>>>> data"=20 >>>>>> problem, we should in fact be researching ways to defeat ZKP/Zerosyn= c=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=20 >>>>> Groups "Bitcoin Development Mailing List" group. >>>>> To unsubscribe from this group and stop receiving emails from it, sen= d=20 >>>>> an email to bitcoindev+...@googlegroups.com. >>>>> >>>> To view this discussion visit=20 >>>>> https://groups.google.com/d/msgid/bitcoindev/f5cf7fb8-61ce-437b-b26b-= 241d47b3fcb5n%40googlegroups.com=20 >>>>> >>>>> . >>>>> >>>> --=20 >>> You received this message because you are subscribed to the Google=20 >>> Groups "Bitcoin Development Mailing List" group. >>> To unsubscribe from this group and stop receiving emails from it, send= =20 >>> an email to bitcoindev+...@googlegroups.com. >>> To view this discussion visit=20 >>> https://groups.google.com/d/msgid/bitcoindev/1d1c5d9c-9b36-4e4b-930c-d2= 3b2f562052n%40googlegroups.com=20 >>> >>> . >>> >> --=20 >> You received this message because you are subscribed to the Google Group= s=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/CAJowKg%2BNuZcowZhKvTH9Dij-= 8eiM0pueX8Ym8RbqUHOfE5Nbjg%40mail.gmail.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/= 03f19c1a-ef1b-40c9-9864-ce84e6b5ddbdn%40googlegroups.com. ------=_Part_409347_958354913.1764442372290 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Erik,

> 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 key= is=20 then defined as `P_i =3D HashToCurve_secp256k1(=CF=83 || i)`, where `i` is = an=20 arbitrary index and the hash-to-curve map is a standard indifferentiable encoding (e.g., IETF RFC 9380). Verifiers check the pairing equation=20 `e(=CF=83, g) =3D e(H(S), PK_root)` once, and thereafter reject any public = key=20 whose curve point does not equal the canonical hash-to-curve output for=20 some disclosed index `i`. Because the signer never chooses curve=20 points=E2=80=94and because hash-to-curve eliminates degrees of freedom=E2= =80=94no=20 entropy remains to smuggle bits into the key, satisfying the same=20 non-malleability criteria used in anti-steganographic constructions.
<= div>
Oh, I confess when you said "BLS" I didn't read the de= tails and then just went off on the assumption you were talking about a rep= lacement of secp with a BLS curve and then outputs being (BLS pubkey, BLS s= ig) i.e. an attached PoK of the key. But now I do actually read what you sp= ecifically meant, I realize I don't understand it: if the secp key is Hash-= to-curve(sigma, i) then you don't have the private key of that pubkey. How = could that be used? I don't get it. Maybe it's because I don't know what S = is, in this scheme, or maybe not.

Lloyd and I re= jected the idea of still using secp but attaching a BLS sig to it. That fee= ls unworkable (mapping keys across groups or w/e), you'd need to just switc= h to a BLS curve entirely, I think.

AdamISZ/waxw= ing

On Saturday, November 29, 2025 at 3:16:34=E2=80=AFPM UTC-3 Greg Maxwe= ll wrote:
You cannot perform pairing on secp256k1 as the DDH is ha= rd in that group, so no BLS signature.=C2=A0 You may find that you make few= er technical errors if you refrain from misrepresenting other people's = ideas as your own original work.


On Sat, Nov 29, 2025 at 5:17=E2=80=AFPM Erik Aronesty <er...@q32.com> wrote:
there is no fundamental change to the cryptogr= aphy.=C2=A0 The beacon proofs are only used for "proof of not spam&quo= t;.=C2=A0 The proven Bitcoin key is the same secp256k1 key and spending is = unchanged.=C2=A0 uxto proofs are not terribly unreasonable given the cost o= f UTXOs=C2=A0

On Sat, Nov 29, 2025, 8:15=E2=80=AFAM waxwing/ AdamISZ <ekag...@gmail.com> wrote:
Hi Erik,

> You can stop arbitrary data encoding in public ke= ys 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 b= een discussing this a bit with Lloyd Fournier on nostr. I think at a theore= tical level this is a very important observation, but at a practical level = not so much. It's also worth noting that something like RSA FDH or hash= based signatures, since they're deterministic (think "no nonce&qu= ot; and no technical ZK property) could 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 on bit= coin (IMO! could be wrong!) because it's an absolutely huge change to t= he crypto without improving quantum resistance (performance issues are I gu= ess an open question, considering batching properties vs raw performance of= a single pairing being bad). And the other reason: no point going this far= without attempting to patch *every* hole that allows data that is not triv= ial. You could argue these holes are trivial: amount data, locktimes (both = nLockTime and nSequence), in/out sequencing not being deterministic, and gr= inding curve points. The 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 before these other things like determi= nistic signatures become relevant, it does seem all very theoretical, if in= teresting.

I guess this would have been better in = the "On (in)ability to embed data in Schnorr" thread but w/e it&#= 39;s all kind of connected I guess!

Cheers,
<= div>AdamISZ/waxwing

On Saturday, November 29, 2025 at 12:43:56=E2=80=AFPM U= TC-3 Erik Aronesty wrote:
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.=C2=A0

Because a BL= S signature is checkable via a pairing equation, verifiers can confirm that= each public key was deterministically forced by the root certificate and n= ot selected to embed arbitrary bits. Under this construction, public keys b= ecome outputs of a constrained randomness beacon rather than an open stegan= ographic channel.

In pra= ctice, 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 def= ined as `P_i =3D HashToCurve_secp256k1(=CF=83 || i)`, where `i` is an arbit= rary index and the hash-to-curve map is a standard indifferentiable encodin= g (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 cur= ve point does not equal the canonical hash-to-curve output for some disclos= ed index `i`. Because the signer never chooses curve points=E2=80=94and bec= ause hash-to-curve eliminates degrees of freedom=E2=80=94no entropy remains= to smuggle bits into the key, satisfying the same non-malleability criteri= a used in anti-steganographic constructions.

This =E2=80=9Cforced randomness=E2=80=9D model paralle= ls techniques in the literature on steganographic resistance and extractabl= e 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 indistinguishability* in pu= blic-key spaces.=C2=A0

T= he 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 <ekag...@gmail.= com> wrote:
Hi Peter, list,

Interesting!

One thought that springs to mi= nd: attempts to ameliorate IBD with ZKP should not forget one thing: what w= e actually want here is succinctness, and not so much ZK. Think SNARK inste= ad 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 strike= s, that any version of these protocols that requires more data/bandwidth pr= obably loses out to versions that have less data/bandwidth. Hmm.
=
=C2=A0It seems to demonstrate, to me, that some kind of &quo= t;data carrying" is required in the "state" (cf the "hi= story"). Ironically recent discussion (see 'On (in)ability to embe= d data into Schnorr' but yeah a googolplex of "discussions" o= n 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 tha= t you are (correctly) insisting, must be done.
(And the corollary= : "harmful data on the blockchain" is a wrong mental model and sh= ould be abandoned, irrespective of architecture.)

= Aside from your *main* concept here, I think the idea that HTLCs require *p= roof* 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 rea= d. Take as contrast the opentimestamps model, where having proof that somet= hing was published, is the main functionality offered/required. I suppose t= here 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 &#= 39;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+...@googlegrou= ps.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 bitcoindev+..= .@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/1d1c5d9c-9b36-4e4b-930c-= d23b2f562052n%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 bitcoindev+...@googlegro= ups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAJow= Kg%2BNuZcowZhKvTH9Dij-8eiM0pueX8Ym8RbqUHOfE5Nbjg%40mail.gmail.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/03f19c1a-ef1b-40c9-9864-ce84e6b5ddbdn%40googlegroups.com.
------=_Part_409347_958354913.1764442372290-- ------=_Part_409346_572659653.1764442372290--