Author: Rusty Russell 2022-03-23 23:50:00
Published on: 2022-03-23T23:50:00+00:00
The Lightning Network developer, Rusty Russell has proposed a new update to the Lightning Network protocol. The proposal suggests reducing UTXO validation from per-channel to per-node and simplifying gossip with only two messages instead of three. Node_announcement_v2 is discarded after a week (1000 blocks), and if two node_announcements claim the same UTXO, the first-seen will be used while others are discarded. Nodes are not required to monitor existence of UTXOs after initial check since they will automatically prune them after a week. The total proved utxo value (not counting any utxos which are spent) is multiplied by 10 to give the "announcable_channel_capacity" for that node. Legacy proofs are two signatures similar to the existing channel_announcement. A channel_update_v2 with no `capacity` is a permanent close. A taproot_utxo_delegated_proof may also be added where UTXOs can sign over to another key so cold storage only needs to sign once, and the other key can sign weekly. It allows "leasing" of UTXOs: one could pay someone to sign their UTXO for their node_announcement, with some level of trust. They could spend the UTXO, which gives a slow degradation as new nodes don't accept your channels but existing nodes don't check until it's due for a refresh.The proposal replaces timestamps with block heights and uses UTXOs to prevent spam. Nodes would send out weekly node_announcement_v2, proving they own some UTXOs, which entitles them to broadcast channels using channel_update_v2; a channel_update_v2 from both peers means the channel exists. However, this could potentially allow parties on the network to utilize existing outputs to advertise false channels and inflate the total network capacity metric. A merkle proof could be added to make it easier for constrained or mobile nodes to verify gossip data. Taproot proofs are a signature of the v1 output over the `node_id`, `utxo` and `blockheight` with prefix "lightingtaproot_utxo_proofsig". Between nodes, there's the question of "who claims this new channel?" Opener claims is logical, but leaks information (though you could definitely pay for the peer to claim it). With dual-funding, it's more complex (some kind of proportional coinflip protocol is possible), but basically, one can always wait for their peer, and if they don't set the claim bit, you can.A convention can be used that a channel_update_v2 with no capacity is a permanent close. The proposal allows "leasing" of UTXOs, enabling one to pay someone to sign their UTXO for their node_announcement, with some level of trust. The proposal also suggests node_announcement_v2 should be discarded after a week (1000 blocks), and nodes do not need to monitor the existence of UTXOs after the initial check since they will automatically prune them after a week. The total proved UTXO value is multiplied by ten to give the announcable_channel_capacity for that node. Rusty questions the usefulness of this in practice as it could lead to inflated numbers for the total node capacity and make path finding more challenging.Channel_id_and_claimant is a 31-bit per-node channel ID that can be used in onion_messages, and one bit is stolen for the claim flag. It provides a unique identifier for that specific node to refer to a peer and saves space in the onion. The proposal simplifies gossip, requiring only two messages instead of three, and reduces the UTXO validation requirements to per-node instead of per-channel. However, it moves to a channel graph that isn't entirely based in the reality of what's routable and would be far more dynamic than it is today. Alex Myers is looking at using minisketch for gossip reconciliation, and there's enough spam in the network that it probably requires some consensus on filtering.Nodes that don't send out weekly node_announcement_v2 would be ignored by others. Channel_update_v2 allows the advertisement of channels that aren't actually anchored in the chain, leading to a more decoupled graph with actual on-chain relationships.
Updated on: 2023-06-03T07:35:05.898375+00:00