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.

> 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.

Ecash has even less data/bandwidth than Bitcoin. Yet people choose not to use
weaker security assumptions in favor of stronger security assumptions.

> 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.)

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.

> Aside from your *main* concept here, I think the idea that HTLCs require 
> *proof* 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 read.

That is not correct. If Alice offers a HTLC to Bob, Alice needs proof that in
the event of a redemption, Bob is forced to publish the preimage in such a way
that Alice can recover it.

The *proof* aspect of this is critical to the security model. It's not enough
that Bob merely promise to give the preimage to Alice: redemption must be
atomic with publication.

> 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*.

> 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?

-- 
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/bitcoindev/aSxXEZzEAlfxLYlY%40petertodd.org.