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