Published on: 2023-08-30T10:42:32+00:00
In the email, the sender discusses the proposal to make peer backups symmetric. They mention a potential issue where if Alice reveals that she has lost her state, Bob might disconnect because he expects Alice to forget his already sent state commitment. To prevent this, Alice could write Bob's state commitment on-chain in an OP_RETURN if Bob does not reveal his state. This ensures that Bob cannot expect Alice to have forgotten his commitment.The email also addresses the distinction between the roles of a wallet provider and the importance of considering a more decentralized model in protocol improvements. The sender agrees with the idea that Phoenix users should not connect to arbitrary nodes and suggests a similar development model for Electrum. However, they believe it would be beneficial to consider a more decentralized model where users have the freedom to connect to any node without needing permission from their software provider.Another topic discussed in the email is the potential risks and complexities associated with cheating attempts by wallet providers in a mobile wallet scenario. The sender argues that it would be risky for providers to cheat because the mobile wallet can constantly check for cheating attempts, and the provider would suffer reputation loss if caught. They emphasize the importance of addressing potential cheating scenarios and suggest that users should take action by closing their channel instead of ignoring cheating situations.The email also explores the idea of a peer backup solution for nodes and discusses various aspects related to reputation loss, replaying old backups, and symmetric resumable channels. It introduces the concept of having a default configuration where if a node runs a public forwarding node, it automatically signals the "backup-provider" feature bit, allowing another node to store its backups with the first node.The sender raises questions about the effectiveness of reputation loss as a deterrent for replaying old backups and suggests stronger measures like actual confiscation of funds. They also discuss the idea of symmetric resumable channels, where both parties provide state backups to each other. To determine who goes first in the channel_reestablish process, an extra preliminary round is suggested.The email further delves into the process for opening post OP_CHECKSIGFROMSTACK on-chain enforcement, suggesting that the channel funding output script needs one taproot branch each for both parties. The sender notes that user error and manual copying/restoring of databases could lead to catastrophic failure with on-chain enforcement.In summary, the email covers various topics related to peer backups, wallet providers, cheating attempts, reputation loss, replaying old backups, symmetric resumable channels, and on-chain enforcement. It provides insights into potential issues and proposes solutions and improvements in protocol design.
Updated on: 2023-08-31T01:58:46.722626+00:00