From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 08 Dec 2025 09:59:22 -0800 Received: from mail-oa1-f56.google.com ([209.85.160.56]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vSfW5-00015k-Cb for bitcoindev@gnusha.org; Mon, 08 Dec 2025 09:59:21 -0800 Received: by mail-oa1-f56.google.com with SMTP id 586e51a60fabf-3f0cc00376dsf6418799fac.0 for ; Mon, 08 Dec 2025 09:59:20 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1765216755; cv=pass; d=google.com; s=arc-20240605; b=eyBH0xVf/vEYP6Ik4EHfb0L0gosgUszTKmPip3re833Crl8xEI1myqvXfqUR7PP5Bz 7kf/b47gpGUg24lNdaiC0dzBr30alkv9wN1mHuHLtCMem7F3v7EreUh3GT8g+ONa274J aI6Cde7Fg1QVDRaPektbpw389iTYdtOrHNj5mHyYj203EG2NLWqatZCKax+86b3So6Go KrSK+FJi7dwWoWBR6Vq9YD+Q2Jf1oR0AYDpzXrUjq3mNbxxyW/QA7Eb0kjaEMRAIVvUt CVtezKc0FwdBGsNYf5fhKW/hsLfDKr534N/SqUvlj5LfIfBcGpIw2urwflxdOQfN+vEB wNZA== 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:content-transfer-encoding:cc:to :subject:message-id:date:from:in-reply-to:references:mime-version :sender:dkim-signature:dkim-signature; bh=kSsZsjom68ElXBhlOdDAijlx/uyHrVVrhqlD9g1x2aA=; fh=QJx22U5j+ZvkD3GI26eQRrMRDtj2D5uNG8k6z6c2fJ8=; b=NP+Xik99WrptkQGuwwCc+wpl/3lAIl3i4EMU04BxprrJ1+U/SuacvZPYBJhKd7oSYE +ZAdlAfQYfT0sbqq/ZR3w+GuaKX/UZvP+Lx3TgBWCoiFsipxHO7zo+bQdao4o7F2hXYy 7+hyEOLJxTFwtNI9XmeGbOcaBsngWR2Z6l+CA0UAayPzmOuj3v8NOHFwN9Yo/lMae3NR 8ywiaCtq/HFs74pVZOD5jPNcyuH/b0ciqDHxRdbu16W9egzbH06OuvBTwJtMLt2RGx/T l/kZGgb+FsCgoc/qE6Jc+PPPX4Ykh7fYskAh0FEbq4+QqiOHlUGIhk5WfJZ9CehWY0ST aq6A==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=bVX9qZyz; spf=pass (google.com: domain of bnagaev@gmail.com designates 2607:f8b0:4864:20::533 as permitted sender) smtp.mailfrom=bnagaev@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=1765216755; x=1765821555; 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:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version:sender :from:to:cc:subject:date:message-id:reply-to; bh=kSsZsjom68ElXBhlOdDAijlx/uyHrVVrhqlD9g1x2aA=; b=dd6AC3VKqhw0VBmkRozyImilmaYobfjZwJz7gUrNmK7edBgYFGEU21M/by30Ku56mW eVIDMHnUs1oyb6jSzNfwR1MfnFyso6wgxtYuKuRlCb4QmTj3GfkECvCOmCvzmzG3RE6Q aVOlyhIk0x+EVtpMpxele7TSbpA7hBWWOzGUjmc1x3EzvO2nZDAzdG22g9AjIB54+1ns FX3gGt+MjwC1Bv9jytc/2CI3QNwQQOwvwUzQbjGOqyLB91x/8orlqdqWBfx0wWz25r0o oSMq7oIUSigRHJwGPIYq/Nbq4QyZk90eqNv3OUmTNV1pHm0F9px9HSNw2sr4eMtyzD/z qlPQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765216755; x=1765821555; 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:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version:from:to:cc :subject:date:message-id:reply-to; bh=kSsZsjom68ElXBhlOdDAijlx/uyHrVVrhqlD9g1x2aA=; b=Spu69Lj4YPRyDo5PYRtqN3Y/T7COauZHQV6sTqKFrUa/NAalWt5kwEBiRigUGnweF0 BgaoO2VyHrRdKLYoNh4H49+1kHQpqi09akxPs2PouLnhVbs2xyB9PTMk8/0H1jB5fGqi WD/RfX6L6/ivSep00kexCvHpGbrJarI73J0w92B7biYApZL7VUXBCF07xPD5oYLHDofQ yOdvL4vHHkUEXYuz/+/8I8FKmrUgMNHg7AFxuz1hp1dGqkgSCn8m/qr77CBXfPUXpCRy T9Wl26JIAERtUeH33U01SZmVla+Q6hOQY4U79gdHeWS99O2It03vBocJEubng3vkD0yA SpvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765216755; x=1765821555; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:content-transfer-encoding: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=kSsZsjom68ElXBhlOdDAijlx/uyHrVVrhqlD9g1x2aA=; b=M4OZOTqixmv3tpg5J/o6rwLNeMAWmDmE3dVPdvzX3zKpLaXJ9wYEzQ9sMoZeOnOyl0 w/KG/MpqcyuFQtCME77ihMr1MK9g5mqo4f8SfkgTRONN9m8N2WPhFsop40540Wr3elvI JZosSuBYkjeMKZNX1SQocfTJQZPBKt6YRz/FgZ4jZgG/g/6KBD+VRN0Jyi2SjK9zxlkV MlqGO2sRXDovK060oXV2kR260XUJWrX+RHJ2T9gieRs07xrM9372pYpIN/muuvQj79Ew UqjmuXuQa8IpxQPlkbJjW5Vw+UMIZ091NRcA4wTN21vIJt03JE0SpbOqr/yVnA6f16MJ RVDA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCXkprdSDG+vfLNTKxa7AQgckgD3htFmzxNBl52SEmsmC/2mVLVNXvPc+FVQU2ScK9wrbbLIPZl5BSnf@gnusha.org X-Gm-Message-State: AOJu0Yw48KmO17cC1ioe01J+KHU6JgI79LjwkCFUo2VGYVeklSF9l4OK KMhN2eckGCSZFgWfoXxMeOarJhp37j6QpNGWlaosYth0yuTXl1yxNj2q X-Google-Smtp-Source: AGHT+IEetiM2j3dCSaQmQxfOQIwrwF8l/fWOccP4ChtNdXzCVz7yeJuGkk/OsKPIxBtTCHkeWoamjg== X-Received: by 2002:a05:6870:678c:b0:3ea:ff22:3ddf with SMTP id 586e51a60fabf-3f543effad3mr4033170fac.25.1765216754661; Mon, 08 Dec 2025 09:59:14 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="AWVwgWaXRcd+K01blvqttVp8+GKe3urrGU4BEq3CA5w8/3MQBA==" Received: by 2002:a05:6871:889c:10b0:3d5:92b8:657b with SMTP id 586e51a60fabf-3f508b67e8bls1620726fac.0.-pod-prod-09-us; Mon, 08 Dec 2025 09:59:09 -0800 (PST) X-Received: by 2002:a05:6808:2213:b0:450:760b:cc94 with SMTP id 5614622812f47-4539e0b84d5mr3917122b6e.49.1765216749455; Mon, 08 Dec 2025 09:59:09 -0800 (PST) Received: by 2002:a05:6808:4a46:10b0:450:c180:fd79 with SMTP id 5614622812f47-4538890812bmsb6e; Mon, 8 Dec 2025 09:34:57 -0800 (PST) X-Received: by 2002:a05:6808:2112:b0:44f:e931:38ab with SMTP id 5614622812f47-4539e087582mr2742025b6e.43.1765215297059; Mon, 08 Dec 2025 09:34:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1765215297; cv=none; d=google.com; s=arc-20240605; b=BGpgIV4GcfSFTXLWnF3TZAb2MPhU5vunjyQ+zlV8uZIoSfE3RBkOPREIEIc4hE2ZDj nRnXxobBet/V5dt8GWXQ6rWUypjscU1kYncGNLSfGsS5kHowTUFi0dTwFdauB5a/XWis F2SvBPaUFxWxGq3OxLN8tAdZscz6f6UWizMK6JhYHxGe0ISxmp5wNvt3qnv9+s+Zd2mA FJYgia5Xr9kN+Dt16dOmKvVODa+dDkflIsEBw0VDpqvYik9BOvttHHbfTGdWBE+dMtgM Mb/wE9OEqBODw2Wiqw09ltfZfXamDzx6ZpSIj5e7wpO+vMfOUxt2m+GsOkK0Egx4myae ReVw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=6+GMbiplcItQFDzh6lyuXbTIrpAzOzPB/PsbA4mWZkU=; fh=rKmWSPUZNEtLKTzRCF0z5VJlgJJjXlGmVECroDAHmlY=; b=cTBCTsX6xwBu0kU1CRQCffg7iXxT5uygCdbl3yT0HEAX1f3JdQPAX8cVOArTvnb0S4 VVzoUL6bjqiCnDOisn6PnJXMJld7Wugi6i+M/Dlc7zUMofDlPOXBiBfAQv0h5eRT/w6z quBnJD4y3xJ1Ibix6p/vQE26L3Gez0c15eOnH5R+U6Eb9OPkck0FkCOWxZKXdCAdSkXf /XbSJfQJjXNSUGtq9yz5G7yXLvtiWQLYww7mwFpWqNp3Kw7pkSVsoykil2/DpyIkNNui Pk0KwSVPZOuBTrG18sSjpnP/jVfQsv3k7DPw/MMPijhhjTSLLRFTc9x5N/1TowsNayr1 Ds/g==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=bVX9qZyz; spf=pass (google.com: domain of bnagaev@gmail.com designates 2607:f8b0:4864:20::533 as permitted sender) smtp.mailfrom=bnagaev@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com. [2607:f8b0:4864:20::533]) by gmr-mx.google.com with ESMTPS id 5614622812f47-4537f8adc49si395143b6e.2.2025.12.08.09.34.57 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Dec 2025 09:34:57 -0800 (PST) Received-SPF: pass (google.com: domain of bnagaev@gmail.com designates 2607:f8b0:4864:20::533 as permitted sender) client-ip=2607:f8b0:4864:20::533; Received: by mail-pg1-x533.google.com with SMTP id 41be03b00d2f7-bc0d7255434so2547837a12.0 for ; Mon, 08 Dec 2025 09:34:57 -0800 (PST) X-Gm-Gg: ASbGncvH4tbRIR9CXtcpq1EOOUVw4DqNRCwRpUPhLkaECqgLzyl4aCDbVF+IIq2Ukl7 ROH26KaLG0GPR87Z/Z7mkzJraZA+zzWxjbhYAoBg49cEofBEwPr+OzXQ335KAAK9gcn+V37Ncjm 5zQKhufJ461s+JCR5JRDqEZ54jXLT1pMDADBKMcbVqJA6lycq+fHDJnyzLbLrS/7CtgJD9XsbK7 DhMgkJ+MWOZ8TJbtULE8Sqqxky8QB1IB3IFD6kWu4fpZLKT5Ga7FZP2kL2Bl7Wmf8HKGf0= X-Received: by 2002:a05:7300:fe09:b0:2a4:3593:4677 with SMTP id 5a478bee46e88-2abc7201554mr5355856eec.19.1765215295996; Mon, 08 Dec 2025 09:34:55 -0800 (PST) MIME-Version: 1.0 References: <91a40bf7-fe9e-43a1-85d1-5889d4b31a7fn@googlegroups.com> In-Reply-To: <91a40bf7-fe9e-43a1-85d1-5889d4b31a7fn@googlegroups.com> From: Nagaev Boris Date: Mon, 8 Dec 2025 14:34:18 -0300 X-Gm-Features: AQt7F2pgMkbo4Jiq8TXFTXPPPtG4-JmGgQJeuvWE65re3Wkyd0qMfDZxFbRv4ps Message-ID: Subject: Re: [bitcoindev] A safe way to remove objectionable content from the blockchain To: "waxwing/ AdamISZ" , Peter Todd Cc: Bitcoin Development Mailing List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Original-Sender: bnagaev@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=bVX9qZyz; spf=pass (google.com: domain of bnagaev@gmail.com designates 2607:f8b0:4864:20::533 as permitted sender) smtp.mailfrom=bnagaev@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 (/) Hi waxwing/ AdamISZ, Peter's main concern is that ZKP-only validation can break HTLCs: if a spend is proven valid with a ZK proof but the actual transaction data (including the preimage) never needs to be revealed on-chain, the HTLC payer (the counterparty relying on that preimage) can't learn it and can't claim its incoming HTLC. That undermines Lightning's security because "proof of publication" collapses into "proof of validity without data availability." Any succinctness/ZK approach for Bitcoin has to preserve the guarantee that the preimage is actually published and readable. Related, if the network drifts toward relying on ZK proofs without simultaneously guaranteeing open access to raw blocks and transactions, block data can become gated by a few data providers. That is a data-availability risk that comes with any ZK deployment that omits strong DA, and it would erode self-sovereignty for routing nodes. Any practical ZK/succinctness design for Bitcoin needs strong data availability, so anyone can fetch raw transactions, not just validity proofs. To Peter: rather than trying to "defeat ZKP," maybe the pragmatic path is to shape any ZK/succinctness work so that the design itself carries the necessary data (e.g., preimages must be published on-chain and retrievable) and ships with strong data-availability guarantees (so raw tx/block data stays broadly accessible, not just proofs). If the "good" ZK system makes data availability a built-in feature, it can occupy the niche and leave less room for alternative designs that drop those guarantees. Best, Boris On Tue, Dec 2, 2025 at 10:05=E2=80=AFAM waxwing/ AdamISZ wrote: > > (apologies to OP; we've drifted off topic here). Answers inline. > > > On Monday, December 1, 2025 at 5:36:55=E2=80=AFAM UTC-3 Peter Todd wrote: > > On Sat, Nov 29, 2025 at 05:54:13AM -0800, waxwing/ AdamISZ wrote: > > Hi Peter, list, > > > > Interesting! > > > > One thought that springs to mind: attempts to ameliorate IBD with ZKP > > should not forget one thing: what we actually want here is succinctness= , > > and not so much ZK. Think SNARK instead of ZkSNARK. > > Which is important; without the requirement for an actual ZK property f= or > > the protocol, you can have it have attached witness that is not secret. > > The Zero-Knowledge part is important to the goal in this specific use-cas= e: > trying to prevent all arbitrary data publication. > > > Yes agreed. (with the strange caveat: the ZK property itself allows data-= embedding almost by force; the reason Schnorr has a data embedding channel = and BLS does not is precisely that BLS does not have a ZK property, which i= tself relates to the fact that it's deterministic (think: no nonce =3D no c= hannel) .. the caveat is not super relevant to some kind of ZK-ed IBD thing= , though, since that's compressing an unfathomable amount). > > > > > It's quite possible that ZKP's are, in the context of decentralized > blockchains, an exploit that will prove to be impossible to patch. Simila= r to > how merge mining is an economic exploit that may well be impossible to pa= tch. > > Sometimes seemingly good ideas are ultimately killed by clever exploits. > > > I have a sneaking suspicion you're wrong here, but I can't justify it. (H= ence 'interesting!'). Would love to hear others opinion on the topic. > > > > Take as contrast the opentimestamps model, where having proof > > that something was published, is the main functionality offered/require= d. > > Nope. OpenTimestamps does not use proof of publication at all. OpenTimest= amps > is a commitment operation: proof that if A was changed, B would have to c= hange > too. The vast majority of OTS timestamps are for private data that is nev= er > published in any way. OTS simply shows that data *existed*. > > That seems like a good correction. So, tamper protection, using binding p= roperty of commitments .. and "proof of existence" is *one* possible functi= on? Is that fair? > > > > I > > suppose there is another way to say it: the channel counterparty needs > > "proof of future publication" in contract setup. That's fair enough but > > it's a very different thing than getting a proof that something *was* > > published. > > It is not a meaningfully different thing. An HTLC is proof that in the ev= ent of > an uncooperative redemption, publication will happen. Slightly changing t= he > time it takes is irrelevant to the general concept. > > Concretely: unless you can propose a technical innovation that somehow tu= rns > this pedantic nuance into a meaningfully different implementation, so wha= t? > > > On reflection I don't see it as strange to make the distinction between t= he two: 1/ proof that something was published in the past and 2/ proof that= conditional on event X occurring, data Y will be published. I guess 1/ is = just, most realistically, a case of publishing raw, unhashed data on a bloc= kchain, then the proof that that event occurred in the past is the onchain = txs ( using op_return or w/e) themselves. As you pointed out, that's not wh= at OTS is doing. Nor is it what an HTLC is doing, that's 2/. > > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > > -- > You received this message because you are subscribed to the Google Groups= "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an= email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit https://groups.google.com/d/msgid/bitcoinde= v/91a40bf7-fe9e-43a1-85d1-5889d4b31a7fn%40googlegroups.com. --=20 Best regards, Boris Nagaev --=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/= CAFC_Vt6HMRoB2xWYUJKLn4Ve8n6MPod6KuTZf87S1Sj%2BGVKQmA%40mail.gmail.com.