Posted by halseth
Feb 4, 2025/14:45 UTC
The discussion revolves around the viability of certain cryptographic operations within a specific context, particularly focusing on the proving times associated with opening channels. The argument presents that while initially, these times might seem excessive, various factors contribute to their potential reduction. These include the infrequency of opening channels, the standard practice of waiting for at least six blocks before announcing a channel, and the consideration of waiting even longer to enhance anonymity. Furthermore, it's mentioned that the task of creating the proof can be allocated to the party with more powerful hardware, and there's optimism about future optimizations and the increasing availability of hardware acceleration.
The conversation transitions into a critique of the non-MuSig version's approach to handling private keys, specifically through hashing for the purpose of single control UTXO. This method is acknowledged as a functional equivalent to using a key image, which raises concerns despite its operational similarity. The original poster reflects on their initial skepticism regarding the safety of this approach but acknowledges having been persuaded of its security. The rationale provided suggests that the exposure of public keys, which are intended to remain confidential between channel parties, doesn't significantly elevate risk since both parties already possess all the information necessary to compromise the channel's existence. The implication is that the potential for such information to leak and allow an observer to link the channel to an output isn't markedly worse than the current situation where channel links are public knowledge.
The dialogue also entertains the possibility of employing Elliptic Curve Diffie-Hellman (ECDH) as an alternative method for enhancing privacy. However, it highlights a significant drawback: the necessity of granting the prover access to the private key or to APIs capable of performing ECDH. This contrasts with the existing methodology where the hash of public keys enables the Lightning Network implementation to generate a standard channel announcement. This announcement can then be transformed into a Zero-Knowledge (ZK) proof by an external tool prior to broadcasting, thereby maintaining the integrity and confidentiality of the process.
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