A safe way to remove objectionable content from the blockchain

In the exploration of enhancing Bitcoin's protocol with zero-knowledge proofs (ZKPs) or any form of succinctness, a pivotal aspect to consider is ensuring the design inherently supports data availability. This means that critical information such as preimages should be mandated to be published on-chain and retrievable by anyone, which not only maintains transparency but also facilitates broad access to raw transaction and block data beyond just the proofs themselves. This approach is argued to potentially carve a niche for "good" ZK systems that integrate data availability as a core feature, thereby diminishing the appeal of alternative designs that might forsake these guarantees.

The dialogue reflects on concerns raised about how purely ZKP-based validation mechanisms could impact elements like Hashed Time-Locked Contracts (HTLCs), crucial for operational security in systems like the Lightning Network. Specifically, if a transaction can be proven valid via a ZK proof without needing to disclose the actual transaction data (including the preimage) on-chain, it could disrupt the HTLC mechanism. Such a scenario would compromise the ability of an HTLC payer to learn the preimage and claim their incoming HTLC, essentially undermining the principle of "proof of publication" by replacing it with a "proof of validity without data availability."

Moreover, there's apprehension regarding the potential for network dependency on ZK proofs without ensuring open access to raw blocks and transactions. This could lead to a situation where block data is controlled by a limited number of data providers, posing a significant risk to data availability. This scenario threatens the self-sovereignty of routing nodes and underscores the necessity for any ZK or succinctness implementation within Bitcoin to prioritize strong data availability. This ensures that anyone can access raw transactions directly, not merely through validity proofs.

The conversation also briefly touches upon technical nuances such as the difference between Schnorr and BLS signatures, noting Schnorr's capability for data embedding due to its non-deterministic nature—a characteristic attributed to its zero-knowledge property. This contrasts with BLS signatures, which lack this feature because they are deterministic. Additionally, there's mention of OpenTimestamps and the dual functions of proofs: one proving the publication of data in the past, and another conditional on an event occurring, ensuring specific data will be published. These discussions highlight the complex considerations involved in integrating ZKPs into Bitcoin, emphasizing the need for careful consideration of data availability and transparency to maintain the integrity and functionality of the network.