Published on: 2020-12-22T02:09:37+00:00
The discussion revolves around the possibility of using Zero-Knowledge Contingent Payments (ZKCP) to prove the discrete log equivalence in a payment scheme. ZmnSCPxj suggests that a ZKCP on the payment point and scalar could be used to gate part of the proof, without revealing the scalar 'z'. However, LL argues that if a secure conditional payment for the proof can be created, it would always prove the existence of the proof, regardless of whether or not payment is made.The article discusses various issues related to the Lightning Network (LN) and suggests possible solutions for each of them. One issue highlighted is hardware failure, which often goes undetected until casual users activate their wallet and use HTLCs. The writer suggests using static-key channels as a way to recover forgotten outgoing channels. However, this method may not work with PTLCs due to the loss of the adaptor signature.Another issue discussed in the article is peer selling private information in unpublished channels. To prevent this, the writer suggests a mitigation strategy that prevents the other party from proving you have a channel with them. The article also examines recovery when a channel state has HTLCs in flight, highlighting the potential risks involved in gifting the money. As an alternative, the writer suggests locking up Bitcoin into channels with well-established lightning nodes.The need for redundancy in data storage is also discussed as a line of defense for routing nodes. The article stresses the importance of detecting hardware failure early on to avoid detectable failure of hardware when the user activates the wallet and uses HTLCs. Static-key channels can allow recovery even for outgoing channels with outgoing HTLC that have been forgotten by the outgoing peer. However, using static-key channels has slightly weaker privacy as published nodes reveal all their channels with other published nodes on the blockchain. Unpublished nodes risk revealing their channels with published nodes via the blockchain.In the email exchange between ZmnSCPxj and LL, they discuss the issue of channel state with HTLCs in flight and how to handle it. LL suggests that one option could be to gift the money to the party offering the recovery settlement or put them onto the settlement tx. However, ZmnSCPxj points out that gifting the money is not a good option as all the claimable value could potentially be in an outgoing HTLC. They also discuss the recovery system and how it should ideally be used by people whose channels are in a HTLC-free state for most of the time.The conversation also touches upon the advantages and disadvantages of using YOLO commitment transactions versus oblivious settlements for recovering funds. Fournier claims that before revealing a recovery, one is guaranteed to have a transaction in hand that they can broadcast first, choose the fee to be as high as they like, and is not replaceable. However, Fournier also mentions potential concerns and privacy issues with the different methods of recovery.The email thread revolves around various aspects of the Lightning Network protocol. The first part of the discussion focuses on the goal of offering a cooperative settlement transaction upfront instead of a commitment transaction. The sender emphasizes the need to avoid losing claim three in order to maintain the applicability of claim one. In YOLO commitment transactions, additional metadata, specifically compressed revocation keys, must be recovered from the other party. The sender explains that a signature on the compressed revocation keys needs to be given before data loss and returned upon reconnection with the commitment transaction.The second part of the thread addresses the consequences of using revocable signature-based channels. It is highlighted that if a node posts a revoked commitment transaction, it loses its static secret key and all funds from all channels with all peers. This can result in a significant loss. The sender agrees with David A. Harding's points about side-channels being effective tools to determine if a node has experienced data loss.The third part of the discussion corrects a mistake regarding LND's "static channel backups" (option_data_loss_protect). The sender clarifies that the goal is to offer a cooperative settlement transaction upfront to the possibly recovering party, rather than a commitment transaction. They explain the potential risks involved with sending commitment transactions, as it exposes the recovering party to the punishment mechanism. The sender argues that using oblivious settlement signatures is preferable because it provides a coherent user experience for recovery. However, they also mention working on another recovery idea that involves peer-provided encrypted backup and full channel restoration.The fourth part of the thread delves into the issue of data loss during network connectivity. Ariel Lorenzo-Luaces suggests that any party refusing to go first cannot be assumed to have lost data. However, the fifth part counters this point, explaining how dishonest counterparties can gather evidence about a recently reconnected node to evaluate the probability of data loss. They argue that knowingly not answering a request can't be distinguished from having connection issues or a machine being turned off.
Updated on: 2023-07-31T23:19:59.124249+00:00