Posted by halseth
Jan 30, 2025/13:34 UTC
The conversation revolves around the technical considerations and decisions involved in developing a Proof of Concept (POC) for a blockchain project, focusing on the use of Utreexo and Groth16 over simpler alternatives like UTXO snapshots and logarithmic-scale ring signatures. Utreexo is highlighted for its deterministic nature and ease of maintenance in a full-node setup, which allows for efficient updates to the accumulator necessary for both creating and verifying proofs. This choice reflects a preference for operational efficiency and reliability in maintaining the blockchain's state.
Groth16 is chosen primarily for its small proof size and compatibility with the Risc0 framework, without further considerations for the POC. This decision underscores the importance of proof efficiency and the advantage of using established frameworks to support the project's technical requirements. The discussion acknowledges that the proposal is designed to be flexible and not strictly tied to any specific proof type, opening the door for future adaptations and optimizations based on evolving needs and technologies.
Regarding the exploration of alternative methods such as ring signatures, the conversation indicates that these have not been extensively considered in this setting. However, there's an appreciation for Risc0's ability to selectively reveal information about outputs and Musig2 keys, highlighting a careful approach to privacy and data disclosure within the system. This selective revelation is crucial for maintaining confidentiality and control over what information is shared publicly on the blockchain.
The dialogue also touches on the concept of "ZK gossip" and the necessity to prevent precise data leaks about channel capacities in the network. It suggests implementing limitations on the precision of capacity announcements to obscure exact values, thereby enhancing privacy. Furthermore, it proposes allowing entities to under-commit to channel capacities on the blockchain while announcing adjusted capacities in channels, introducing flexibility and discretion in how commitments are represented and communicated. This strategy involves adjusting the proof assertion to accommodate a multiplier effect on the committed value, further embedding privacy and strategic ambiguity into the system's design. This discussion reflects a nuanced understanding of the trade-offs between transparency, privacy, and functionality in blockchain networks.
TLDR
We’ll email you summaries of the latest discussions from authoritative bitcoin sources, like bitcoin-dev, lightning-dev, and Delving Bitcoin.
We'd love to hear your feedback on this project?
Give Feedback