A safe way to remove objectionable content from the blockchain

The conversation initiated by Boris and continued by waxwing/AdamISZ revolves around the intricacies of incorporating Zero-Knowledge Proofs (ZKPs) and data availability within Bitcoin's ecosystem, specifically addressing concerns related to Hash Time-Locked Contracts (HTLCs) and the overall security and accessibility of transaction data. The discourse opens with Boris highlighting the importance of designing early systems that support an incentive-compatible equilibrium, emphasizing the need for Data Availability (DA) and forced publication to prevent a scenario where only a few parties have access to full data sets, particularly in the context of UTXO accumulators.

Waxwing/AdamISZ responds by underscoring the necessity of embedding essential data, such as preimages, within the blockchain itself, ensuring they are on-chain and retrievable. This approach aligns with the broader goal of maintaining strong data-availability guarantees, ensuring that raw transaction/block data remains widely accessible beyond mere proofs. The dialogue hints at a radical redesign where mining could pivot to rely solely on an accumulator over the UTXO set, which would fundamentally alter how transactions are verified and necessitate set membership proofs for transaction inputs.

Boris further elaborates on potential pitfalls of relying exclusively on ZKP for transaction validation. He argues that if transaction data, including preimages necessary for HTLCs, aren't required to be published on-chain, it could severely undermine the Lightning Network's security model. This scenario would collapse the distinction between "proof of publication" and "proof of validity," eliminating the assurance that necessary data for claim verification is publicly accessible. There's an acknowledgment of the risk that ZK deployments without strong data-availability (DA) assurances could lead to a centralization of block data, controlled by a limited number of providers, thereby eroding the principle of self-sovereignty for network participants.

The exchange concludes with reflections on the nature of proofs within the blockchain sphere, distinguishing between proofs of existence versus conditional proofs dependent on specific events. The discussion touches upon the functionality of OpenTimestamps and its role in verifying the occurrence of events or the commitment to certain data at past points in time, contrasting this with the operational mechanics of HTLCs which are predicated on conditional data publication based on event outcomes.

This thread, part of the Bitcoin Development Mailing List, encapsulates a nuanced debate on balancing innovation in succinctness and zero-knowledge proof technology with foundational principles of data availability and transparency, crucial for the sustenance of decentralized financial networks like Bitcoin.