Proposal for "local" channel announcements. [combined summary]



Individual post summaries: Click here to read the original discussion on the lightning-dev mailing list

Published on: 2018-11-04T15:04:14+00:00


Summary:

In a recent email exchange between ZmnSCPxj and Rusty Russell, ZmnSCPxj raised concerns about the flawed incentives for non-public channels. These channels aim to keep public maps small, but users of these channels are not compensated for providing this service. Instead, they actually pay for their non-public channels by revealing to the other user that they are the sole source or destination of payments. To address this issue, ZmnSCPxj proposed an alternative mechanism where the initiator of a channel can indicate whether it is "local" or "global". "Local" channels would only be gossiped up to a limited number of nodes, reducing map sizes while increasing the anonymity set for possible users of the local channel.ZmnSCPxj suspects that there is a "last mile" problem with non-public channels and their incentives. Rusty Russell agrees that public nodes have an information advantage in this scenario, but he believes that more routes mean more fees. However, Rusty acknowledges that a peer can always offer substandard service, so he does not consider this situation to be worse.Further clarification was sought by ZmnSCPxj regarding private and public nodes in a channel. According to ZmnSCPxj, there is a "private" node with all non-published channels, and a public node that benefits from knowing that everything passing through the channel with the "private" node originates solely from it. Rusty confirms that this understanding is correct.Rusty also proposes a solution to increase deniability of payments for nodes with only private channels. Currently, these nodes lose deniability as unannounced channels reveal the sender. The suggested mechanism involves creating "local" channel announcements that only propagate one hop, thereby enhancing deniability. In this process, the public node suggests a fake short channel id unique to it. If the private node agrees to use this id for the channel announcement, it responds with a signature on the `local_channel_announcement` message using its chosen key. This generates a `local_channel_announcement` created by the public node, which is then sent to its peers. Although the peers may consider it a valid `channel_announcement`, they should not propagate it. The `Channel_update` operates as before, following a similar non-propagation rule.Overall, the exchange between ZmnSCPxj and Rusty Russell highlights concerns about the flawed incentives for non-public channels and proposes alternative mechanisms to address the issue. It also discusses the advantage of public nodes in terms of information and suggests ways to increase payment deniability for nodes with only private channels through the creation of "local" channel announcements. Feedback on these proposals is welcome.


Updated on: 2023-07-31T20:36:53.983988+00:00