From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 29 Nov 2025 10:16:42 -0800 Received: from mail-oa1-f62.google.com ([209.85.160.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 1vPPUu-0000Ah-GL for bitcoindev@gnusha.org; Sat, 29 Nov 2025 10:16:41 -0800 Received: by mail-oa1-f62.google.com with SMTP id 586e51a60fabf-3e89d22a84fsf831283fac.2 for ; Sat, 29 Nov 2025 10:16:40 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1764440194; cv=pass; d=google.com; s=arc-20240605; b=EuBakA9g3oSJIADiOAb7bMo15X6L7lJkSRWNeWTBsgf6q05DLObfctY81Z+1fLXvO5 vuxIso/su7eKKTYeL2AfUyqaB9EIEXEsZnL81NkMInpN8AK/IWu07+4U0Te2hrV/Yj0L sKBr+EPLmqFSyGXGhL+Wij9ijXnPgOmYu+LNIBKY2iiRLF0qTsiaWvhQsRpcdmssussV AX2mwHXDt2MWW7LJA9IJYDJTbGpmC8iCuq4RatVWgmH/yRRNn6LS3XJhXfERsexyb/BY zTbRoZYIgKI86W7aZ8Hirpfd9vU+Rdd9nNiS83bzZZ1y8z8Z+ZVOV0ftet1nffQfPDdp ISwA== 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 :dkim-signature; bh=fQ8zqXGEFeq6uwG4wAkRkqEopBCv7H2bqRdoBUHvZfY=; fh=VLEQ/ans+mjRbX4CIde2c2X2Dt2Mf55QJj+OzZVKaVk=; b=XacFgKs7I2brdZvD4EHHIUU5VsaGMKkn90ANxO9/fNpBFudCp2YDW73gBykXQ9jtfr V6JiAAyhp5kmrervFqzxsFUJbX0NCnbJMtMUH9S3Zpn+V0hJk+/e//5u2X/Ho96LrzGv SM3sY37g6ksy31OYDdaqbgzNbkf8O7lTZ77hkMWMzYa4+mAbtSyV2PLnomkKw6S9XZeY CA7q/4d7/k5dRSHn9rZuC1J1I89VjJbsprkGgmHzA4+j1I1vtD6TWLxiFZpUrzEFYPtn 4JBrAEafSc0Rf3fALza3onkw5cGROMcwyYLjofi4cihOqPnt1OFtExJ8v26S3HusUYY2 bw6g==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=HoendBYH; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::430 as permitted sender) smtp.mailfrom=gmaxwell@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1764440194; x=1765044994; 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=fQ8zqXGEFeq6uwG4wAkRkqEopBCv7H2bqRdoBUHvZfY=; b=M5fb5/wnjvofiuVfHk9nSdt+55MI0ZxHGWtQ+7SdCVi8HRJownIFAW2HqSXextCHVf mfGZlLZcsLzELrQA5QBKLSgF8PhhOZMHYd7UyOm+4fgB9Ey35aWvlPfAFlRGoRNbbco2 eOUPohUgshbWbrQ+CwuF1ApdZ5GKtFTNPfEdMfKrMLjdEoAK+lesoJItD1JpSgIVBI09 PyFY1HgSD9bXb8b3dSacmZaU9R/bU0jZLoMhhqd2iJBl0DqyTM78VCG3LZC8SRey7XYz 4jswJoz2+s0U7D//AtaS38eXvD/27MDKsjfk+BJcWa06peEbvvI0TuxVZLWxZK3Nf9nw oZ7Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764440194; x=1765044994; 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:from:to:cc:subject:date:message-id:reply-to; bh=fQ8zqXGEFeq6uwG4wAkRkqEopBCv7H2bqRdoBUHvZfY=; b=DDpVRMmJX4Z7w4wtoj1tusKocbUPzuLvrapQ3aoIaLJOz7JFJDXfbRZAinTcv65Bci P0MHOjgqxjk3pM155c/RfdXNUIdAem6WGp3XcdHdiQNCZsyZ0N7YJg9IsIJ6O5rj8CJg xaMk1/6K0s9fBw8KLxjYThcC+YLQDV7EZVM26oLKXU9msOUenAqpcxoE/KRypNIWWBVc vwDesprenG1vivdFoQgzKzVI4ojHli4iHWZP8PUpHyNLup01plqTPVP8thad6DGscpdZ 9CWwzzSXl9eerkzeA2pau4/isGz3VNI1fqM7FlNecTrg0OWoXuSbaMQk0OzwYbUw/QZG H2ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764440194; x=1765044994; 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=fQ8zqXGEFeq6uwG4wAkRkqEopBCv7H2bqRdoBUHvZfY=; b=bY8fiXhuykzScJZtdSsA5LCUFxIIfsc0M+qDFB+Wc5q4ViidHJUiP3+eQ0bfPAvWE/ TVv1qutnZaAzW2hRuz6JOdqGfQ2Wj79/orEy1KPCUTh7+6MGPENeVByXENJiZ3KVxIv5 jo/YtrXsXrFfryDrWaNn9cL0DSEL0gdNLhOlbCZDtPWfUO6kQ3DUdQFZDZu0ELdr2bJf lImzysBw+v9PiqY7ijmESOY6x2XQrDn4Jp/ivkrfLSfcGgbypcrK+Fy04QGPNsk6kmnD uC/1u1mhEBCLo3NxX6IisIRX9dX85BiMKOD4Fdx7IlO3FOdNfUnmULs3FLu/KCJZ7xz+ qI0Q== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCXr3Jkl0pTpz4zzPZ8fUo9lwrTq9xppnGS/F+EdXuNDjum7p4Dexm7nra82XIYjiIi3dGhHVxP/e5O9@gnusha.org X-Gm-Message-State: AOJu0Yz9AISbi+XtbQA/yOGL0zinxeCALzYFMvqry3A03HJPc3/sMAip SaowtWD/RgyPrM70NKCsl5XdxsmXAZeniT+cWYavhO43iUCoKSe8JiqU X-Google-Smtp-Source: AGHT+IEiJ21cCRma6lAoyYOdAxaHCjBdsTqYLsKSyHD179/6M46w+7J9leP0+YEi1xCCDeps5R5qyg== X-Received: by 2002:a05:6871:ac06:b0:3e7:f374:8dd5 with SMTP id 586e51a60fabf-3ecbe324a3emr15057534fac.15.1764440194293; Sat, 29 Nov 2025 10:16:34 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+ZZfvbipZsJt6DR6k8yB7HBJvXeu7ek9BNWujlH/y3lag==" Received: by 2002:a05:6870:12d8:b0:3ec:5edf:7cfc with SMTP id 586e51a60fabf-3f0d20ddfdals1249523fac.1.-pod-prod-04-us; Sat, 29 Nov 2025 10:16:29 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCWyPx4J9J/g5UdMANKlDgE6UpQM9I6Y5fPxbocYFAnW6UQKvvTfLZxcAI9jkSFFOCgxJGNwMd53JQdE@googlegroups.com X-Received: by 2002:a05:6808:2003:b0:450:839a:557 with SMTP id 5614622812f47-4511572fbe0mr11576367b6e.9.1764440189408; Sat, 29 Nov 2025 10:16:29 -0800 (PST) Received: by 2002:a05:620a:a34c:b0:8b2:e00e:5a07 with SMTP id af79cd13be357-8b4ec4aa272ms85a; Sat, 29 Nov 2025 10:15:29 -0800 (PST) X-Forwarded-Encrypted: i=2; AJvYcCXMYjcigws9hywO1NfeA0eYP1k2hCXWhA3344J6RCVmI+MfsQLGRPL/FzgaTPZif0xhY7SMCH0F1CZ7@googlegroups.com X-Received: by 2002:a05:6214:3d05:b0:880:5bff:74d6 with SMTP id 6a1803df08f44-8847c536166mr490832066d6.51.1764440128401; Sat, 29 Nov 2025 10:15:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1764440128; cv=none; d=google.com; s=arc-20240605; b=KVU/9/l/ib69uIDXVhQW1k5NE26ThG03qieQ4Kdyqneg+sqXmBPFeK2TsLs9xTchiy GopkDKDbvPNDshTuLiSapX3BTYNuMXejsvnGQHb9XxqIxkRGyp+fZI9kZK5d46P25SMj NAdRtFtQ2kx/91CRXBFOKUhoviBkKyAisNpR8qyDWsJj7ltMdWwSuqyV2IaQuctLvIXc f+vF5pAp16YrHkB+OnGL2gILpHCmR2rQC4TBY8nM8PnabCfD4XVsFRioOw3LjNNcdGhN nLHn8wSVfBJ5rhs7uWe3ZZzrGfQwiTyA7MstapKj8/5j+BiTbOsUKQJiX4bIFIJbAClF 5X/A== 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=3wEZLrAQURo8VT0KNbENnemQ5qm+cgSLArNDkWvSU3w=; fh=8qlSF/XtwGvQr6HWPy/8p6eyzrhNGie5M5P4htA9qA4=; b=WFZKoNilUTUMxmKLEXchw026EE0u01t1SibTxVtaVDUBCOI2cHLVbMN5pRaCOqLeeb NeFbk22GH/ysvrhwGe4+USMq7TTXi+eo5xO0JfR/reVwj7/0wBMBaczZEmKEWRFDx8b4 kTX1rsIqaOA7XcRhS5mXqqMIVKEGYWNB3GbJq1N9e/zeuhTm4mIwizMbU7yZifXxbaHb fkqTBHaO21PsjGQO3MtNC0f6ARLnYnpyjRIvwoeybI3IM5KQ7WfSMMgu6dctzMOxXL1F 7az/tHYqmUhy6cjsBTbBXn485rzBePkNJQe3LviIOEM24xRbvqtA16g3W/dsgl2qLH4Z /+9Q==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=HoendBYH; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::430 as permitted sender) smtp.mailfrom=gmaxwell@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com. [2607:f8b0:4864:20::430]) by gmr-mx.google.com with ESMTPS id 6a1803df08f44-88652b02d8bsi2304776d6.11.2025.11.29.10.15.28 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 29 Nov 2025 10:15:28 -0800 (PST) Received-SPF: pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::430 as permitted sender) client-ip=2607:f8b0:4864:20::430; Received: by mail-pf1-x430.google.com with SMTP id d2e1a72fcca58-7aad4823079so2462947b3a.0 for ; Sat, 29 Nov 2025 10:15:28 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCVrk+GCPptn3R6grAB3mpcxMg7o32O5uIWnM0hGJ+/et9XKY3lwXlcsB7PzaNtqi6IQy0LE+08W+qG7@googlegroups.com X-Gm-Gg: ASbGncswXNx8FVY9fyRFim1HR/9Z3j/W5zEtqY8yGpp28AzZDMP2HcgU/xW85UeWMty HZgi1/0hGW0U4hJxrSXhMaR9kzQcnBr4A++1Mndz9fyumeS8RJ0R5HJEGl3MWjOfIQ0/H1Mqz+Y TOIDBkTJTxsWYHyygUTQ1oYr/E3i/J8W872iC5jIWlrRMnHtFTtB85gXGHdQNAePI1lL4UmarIK 4NCEQPnezWqJdNHVUTcvymICXWQuqS9JCr9Pc/7fKGU1gjubMHq+6oLafUm5BYrZ+PnDgdg7ea4 Y3mHub9tn1vpPwLAENJs3vwJBeUCpWUtHs6nnv81s+2njGCODFo= X-Received: by 2002:a05:7022:30a:b0:11a:2e9c:1130 with SMTP id a92af1059eb24-11c9d711b60mr21572728c88.7.1764440127243; Sat, 29 Nov 2025 10:15:27 -0800 (PST) MIME-Version: 1.0 References: <1d1c5d9c-9b36-4e4b-930c-d23b2f562052n@googlegroups.com> In-Reply-To: From: Greg Maxwell Date: Sat, 29 Nov 2025 18:15:15 +0000 X-Gm-Features: AWmQ_bmDvBh3CvASgMmB1v3aCBtA0I3L4uW09ei392qM_6zNLjV63miaEhRlzkI Message-ID: Subject: Re: [bitcoindev] A safe way to remove objectionable content from the blockchain To: Erik Aronesty Cc: "waxwing/ AdamISZ" , Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="0000000000000308c50644bfbb34" X-Original-Sender: gmaxwell@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=HoendBYH; spf=pass (google.com: domain of gmaxwell@gmail.com designates 2607:f8b0:4864:20::430 as permitted sender) smtp.mailfrom=gmaxwell@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=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.5 (/) --0000000000000308c50644bfbb34 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable You cannot perform pairing on secp256k1 as the DDH is hard in that group, so no BLS signature. You may find that you make fewer 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 wrote: > there is no fundamental change to the cryptography. The beacon proofs ar= e > only used for "proof of not spam". The proven Bitcoin key is the same > secp256k1 key and spending is unchanged. uxto proofs are not terribly > unreasonable given the cost of UTXOs > > 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 every >> key to be the **unique hash-to-curve output** of a publicly verifiable B= LS >> root signature, rather than a user-chosen point on secp256k1. >> >> Indeed, absolutely correct (afaik!), I had recently been discussing this >> a bit with Lloyd Fournier on nostr. I think at a theoretical 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" and no technical ZK proper= ty) >> 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 bitcoin (IMO! could be wrong!) because it's an absolutely huge >> change to the crypto without improving quantum resistance (performance >> issues are I guess an open question, considering batching properties vs = raw >> performance of a single pairing being bad). And the other reason: no poi= nt >> going this far without attempting to patch *every* hole that allows data >> that is not trivial. You could argue these holes are trivial: amount dat= a, >> locktimes (both nLockTime and nSequence), in/out sequencing not being >> deterministic, and grinding curve points. The obviously much more releva= nt >> 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 deterministic signatures become relevant, it does seem all v= ery >> theoretical, if interesting. >> >> I guess this would have been better in the "On (in)ability to embed data >> 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 Aronest= y 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. >>> >>> Because a BLS signature is checkable via a pairing equation, verifiers >>> can confirm that each public key was deterministically forced by the ro= ot >>> certificate and not selected to embed arbitrary bits. Under this >>> construction, public keys become outputs of a constrained randomness be= acon >>> 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 indifferentiabl= e >>> 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 who= se >>> 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 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 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 sec= ure steganography* and >>> Bellare=E2=80=93Ristenpart=E2=80=93Tessaro=E2=80=99s analyses of *chann= el indistinguishability* 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 succinctnes= s, >>>> 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 se= cret. >>>> >>>> Then a counter-thought strikes, that any version of these protocols >>>> that requires more data/bandwidth probably loses out to versions that = have >>>> less 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 discussi= on >>>> (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 tha= t'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 publicat= ion. >>>> A wronged channel party needs to read the preimage, not have proof tha= t it >>>> can be read. Take as contrast the opentimestamps model, where having p= roof >>>> that something was published, is the main functionality offered/requir= ed. I >>>> suppose there is another way to say it: the channel counterparty needs >>>> "proof of future publication" in contract setup. That's fair enough bu= t >>>> 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 = 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. >>>>> > >>>>> > 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 ca= n >>>>> be >>>>> > convinced that H(X) =3D Y even if X is deleted and no one knows wha= t >>>>> the >>>>> > 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 >>>>> number of >>>>> > transactions or bytes compressed. This approach does not require an= y >>>>> > changes to Bitcoin and you could implement a Bitcoin full node toda= y >>>>> 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 rule= s >>>>> and were >>>>> thus valid. However, valid block hashes alone are insufficient to min= e >>>>> on 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 th= e >>>>> incentives to distribute block data in a form that allows other miner= s >>>>> 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 >>>>> 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 >>>>> validity 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 >>>>> block 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+...@googlegroups.com. >>>> >>> To view this discussion visit >>>> https://groups.google.com/d/msgid/bitcoindev/f5cf7fb8-61ce-437b-b26b-2= 41d47b3fcb5n%40googlegroups.com >>>> >>>> . >>>> >>> -- >> You received this message because you are subscribed to the Google Group= s >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n >> email to bitcoindev+unsubscribe@googlegroups.com. >> To view this discussion visit >> https://groups.google.com/d/msgid/bitcoindev/1d1c5d9c-9b36-4e4b-930c-d23= b2f562052n%40googlegroups.com >> >> . >> > -- > 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/CAJowKg%2BNuZcowZhKvTH9Dij-8= eiM0pueX8Ym8RbqUHOfE5Nbjg%40mail.gmail.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/= CAAS2fgQfmSsvFwm5n2v7XjV3cc4KUxqpSwCoa30YXPDVEqj1Fg%40mail.gmail.com. --0000000000000308c50644bfbb34 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You cannot perform pairing on secp256k1 as the DDH is= hard in that group, so no BLS signature.=C2=A0 You may find that you make = fewer 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 <erik@q32.com> wrote:
there is no fundamental cha= nge to the cryptography.=C2=A0 The beacon proofs are only used for "pr= oof of not spam".=C2=A0 The proven Bitcoin key is the same secp256k1 k= ey and spending is unchanged.=C2=A0 uxto proofs are not terribly unreasonab= le given the cost of UTXOs=C2=A0

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

> You can stop arb= itrary data encoding 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 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 '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-61= ce-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+unsubscribe@googlegroups.com. To view this discussion visit h= ttps://groups.google.com/d/msgid/bitcoindev/1d1c5d9c-9b36-4e4b-930c-d23b2f5= 62052n%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+unsubscribe@googlegroups.com.
To view this discussion visit https:= //groups.google.com/d/msgid/bitcoindev/CAJowKg%2BNuZcowZhKvTH9Dij-8eiM0pueX= 8Ym8RbqUHOfE5Nbjg%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/ms= gid/bitcoindev/CAAS2fgQfmSsvFwm5n2v7XjV3cc4KUxqpSwCoa30YXPDVEqj1Fg%40mail.g= mail.com.
--0000000000000308c50644bfbb34--