From: Boris Nagaev <bnagaev@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] A safe way to remove objectionable content from the blockchain
Date: Tue, 9 Dec 2025 11:32:48 -0800 (PST) [thread overview]
Message-ID: <ec60219f-f2c7-4639-8c45-d3f3938241b7n@googlegroups.com> (raw)
In-Reply-To: <d5eebd82-7f8f-4245-9bb6-fb77020dad72n@googlegroups.com>
[-- Attachment #1.1: Type: text/plain, Size: 8365 bytes --]
Hi waxwing/AdamISZ,
On incentives: agreed that "good" only matters if it's an equilibrium. The
aim is to shape early design choices so the incentive-compatible
equilibrium includes DA and forced publication, rather than slipping into a
DA-weak equilibrium where only a few parties hold full data.
> what if mining was done just on an accumulator over the utxo set, instead
of the utxo set itself?
If miners and nodes only see an UTXO accumulator, how do HTLCs survive? The
HTLC success spend path needs the preimage to be revealed and readable. How
does this fit in an accumulator-only mining model, and what forces
publication so the payer can claim its incoming HTLC?
Best,
Boris
On Tuesday, December 9, 2025 at 11:29:24 AM UTC-3 waxwing/ AdamISZ wrote:
Hi Boris,
> 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.
re: "a good ZK system makes data availability a built-in feature", I think
this concept of "good" is not very relevant if it's counter to incentives
(hence my earlier "Hmm" comment; incentives matter).
Meanwhile I find myself reflecting more on Peter's original point (how
spectacularly deleterious to mining this could be, let alone the data
availability stuff), and I'm wondering if we can just go radically in the
opposite direction: what if mining was done just on an accumulator over the
utxo set, instead of the utxo set itself? Complete redesign of the
protocol, but .. possible, I think? Tx inputs would have to have set
membership proofs. I wonder if anyone's done this particular analysis.
Cheers,
waxwing/AdamISZ
On Monday, December 8, 2025 at 2:59:14 PM UTC-3 Nagaev Boris wrote:
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 AM waxwing/ AdamISZ <ekag...@gmail.com> wrote:
>
> (apologies to OP; we've drifted off topic here). Answers inline.
>
>
> On Monday, December 1, 2025 at 5:36:55 AM 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
for
> > 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-case:
> 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 itself relates to the fact that it's deterministic (think: no nonce =
no channel) .. the caveat is not super relevant to some kind of ZK-ed IBD
thing, though, since that's compressing an unfathomable amount).
>
> <snip>
>
>
> It's quite possible that ZKP's are, in the context of decentralized
> blockchains, an exploit that will prove to be impossible to patch.
Similar to
> how merge mining is an economic exploit that may well be impossible to
patch.
>
> 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.
(Hence '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/required.
>
> Nope. OpenTimestamps does not use proof of publication at all.
OpenTimestamps
> is a commitment operation: proof that if A was changed, B would have to
change
> too. The vast majority of OTS timestamps are for private data that is
never
> published in any way. OTS simply shows that data *existed*.
>
> That seems like a good correction. So, tamper protection, using binding
property of commitments .. and "proof of existence" is *one* possible
function? 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
event of
> an uncooperative redemption, publication will happen. Slightly changing
the
> time it takes is irrelevant to the general concept.
>
> Concretely: unless you can propose a technical innovation that somehow
turns
> this pedantic nuance into a meaningfully different implementation, so
what?
>
>
> On reflection I don't see it as strange to make the distinction between
the 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
blockchain, 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 what 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+...@googlegroups.com.
> To view this discussion visit
https://groups.google.com/d/msgid/bitcoindev/91a40bf7-fe9e-43a1-85d1-5889d4b31a7fn%40googlegroups.com.
--
Best regards,
Boris Nagaev
--
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/ec60219f-f2c7-4639-8c45-d3f3938241b7n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 10278 bytes --]
next prev parent reply other threads:[~2025-12-09 22:13 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-20 1:57 Lazy Fair
2025-11-20 18:45 ` Greg Maxwell
2025-11-23 6:37 ` Saint Wenhao
2025-11-20 21:21 ` Ethan Heilman
2025-11-29 9:25 ` Peter Todd
2025-11-29 13:54 ` waxwing/ AdamISZ
2025-11-29 15:41 ` Erik Aronesty
2025-11-29 15:56 ` waxwing/ AdamISZ
2025-11-29 17:03 ` Erik Aronesty
2025-11-29 18:15 ` Greg Maxwell
2025-11-29 18:52 ` waxwing/ AdamISZ
2025-11-30 14:39 ` Peter Todd
2025-12-02 12:33 ` waxwing/ AdamISZ
2025-12-08 17:34 ` Nagaev Boris
2025-12-09 14:24 ` waxwing/ AdamISZ
2025-12-09 19:32 ` Boris Nagaev [this message]
2025-12-10 13:57 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ec60219f-f2c7-4639-8c45-d3f3938241b7n@googlegroups.com \
--to=bnagaev@gmail.com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox