Published on: 2021-05-03T22:42:10+00:00
In a discussion about a new backup scheme for Lightning Network nodes, Rusty Russell raises concerns about the proposed method, particularly regarding the removal of the ability to update a channel without access to the node's secret key. However, he suggests that more reliable backups could solve this issue. He also mentions other potential solutions, such as OP_RETURN tagging opens and deterministic key generation. Despite his concerns, Russell does not dismiss the possibility of implementing the backup scheme in the future.Lloyd Fournier questions the need to bump the generation until a funding transaction is confirmed. Initially, he couldn't think of a reason why someone would want to open two channels to the same node simultaneously instead of putting all their funds into one funding. However, he later retracts his point after considering a few reasons.Rusty Russell discusses a proposed method for channel establishment workflow and expresses concerns with its implementation. He believes that removing the ability to update a channel without access to the node's secret key is not ideal. He proposes an alternative method using encrypted blobs served by peers, assuming at least one peer is honest. Lloyd Fournier suggests eliminating all "basepoints," but Russell notes that signing the commitment_tx or htlc_tx would require knowing the node's secret key. They also discuss the `tx_add_input` message and the importance of proper specification and use of the `htlc_basepoint` and `payment_basepoint` in ensuring secure transactions.In an email exchange, Rusty Russell and Lloyd Fournier discuss the elimination of "basepoints" in the Lightning Network's funding protocol. While Rusty suggests using SHA256 to create different r values for each counter value, Lloyd proposes eliminating all "basepoints" by using the node pubkey as the basepoint for everything and randomizing it with the shared secret for each purpose. However, Rusty notes that this idea requires knowledge of the node's secret key to sign certain transactions. To address this issue, he reluctantly adds `commit_basepoint` from which other points can be derived. Alternatively, nodes can set their funding_pubkey to a specified DH tweak of the nodeid to offer backup-free channel recovery.Lloyd Fournier proposed an idea to recover lightning channels after losing channel state in a boating accident. Currently, users can use static channel backups, which involve keeping a list of channel ids and nodes they had channels with, to remember who they had channels with and ask them to force close the channel. However, Fournier suggests that this process can be done without the need for a channel backup by making a slight change to the lightning protocol.Fournier's proposal involves using a deterministically randomized version of the node's static public key as the `funding_pubkey` in the open channel message, instead of the temporary_channel_id. By performing a Diffie-Hellman operation with the other party's public key, scalars r1 and r2 can be deterministically produced. These scalars can then be used to create 2-of-2(r1*G + P_local, r2*P_remote) as the script pubkey of the funding output. This would allow users to know what their funding outputs with each node look like without interacting with them.This solution would enable users to locate their channels in the UTXO set when channel state is lost. Non-enterprise users, in particular, would benefit from this improvement as they exclusively have channels with well-known reliable public nodes whose public keys can be discovered through routing gossip or public indexes. The proposed method also reduces the amount of data that needs to be stored.Another approach suggested by Gijs involves creating a synthetic static channel backup to trigger the data loss protection protocol. By restoring this backup, a `channel_reestablish` is sent to the remote peer, forcing them to force close the channel. The `per_commitment_point` received from the remote peer can then be used to derive the private key needed for sweeping funds. While Fournier's approach covers more cases, Gijs's approach only applies to certain edge cases. However, Gijs's approach can be implemented without changes to the Lightning protocol.Overall, Fournier's proposal and Gijs's approach offer potential solutions for recovering lightning channels after losing channel state, with Fournier's proposal providing a more comprehensive solution. The community is supportive of exploring these ideas further, although there are some concerns about the security implications of the proposed changes.
Updated on: 2023-07-31T23:17:02.167432+00:00