[Lightning-dev] Unpublished Channels, and a Proposal for Local Channel Publication
ZmnSCPxj at protonmail.com
Thu Oct 24 15:20:59 UTC 2019
Good morning list,
As is my wont, I again send unnecessary unsolicited spam on this list.
The Axiom of Terminus
Let us consider the below trivial Lightning Network:
A <-> B <-> C <-> D
There are three channels:
Now, let us consider, what happens if one of these channels is unpublished but the remaining two are published, and whether A and D can send and receive payments back and forth.
Let us consider in terms of the current available specs.
Suppose AB is unpublished, but BC and CD are published.
In that case:
* Payments from A to D work, by simply making the first channel the unpublished channel AB which is directly known by A.
* Payments from D to A work, by A revealing the unpublished channel AB via the `r` field of the invoice sent to D.
Suppose CD is unpublished, but AB and BC are published.
In that case:
* Payments from A to D work, by D revealing the unpublished channel CD via the `r` field of the invoice sent to A.
* Payments from D to A work, by simply making the first channel the unpublished channel CD which is directly known by D.
Suppose BC is unpublished, but AB and CD are published.
In that case:
* Payments from A to D are impossible.
* Payments from D to A are impossible.
The reason for the impossibility (given the current state of the BOLT spec) is that neither A nor D have knowledge of the unpublished channel BC.
Thus as far as A and D are concerned, they live on separate islands of the Lightning Network, and the channel BC cannot be used to route, due to the fact it is unpublished.
Statement of the Axiom of Terminus
> A payment route may have an unpublished channel at one or both termini (start and/or end of route), but not in the middle of the route.
This so-called "axium of terminus" is an assumption that underlies payment analysis on the Lightning Network.
The basis for accepting this assumption is the logic shown above: BC cannot be used in forwarding a payment from A to D, and thus it cannot be the middle of the route.
Thus, unpublished channels can only be the start and/or end of a route.
More concretely, analysis of payments over the Lightning Network can be simplified by accepting the axiom of terminus as true:
* If a node receives from any channel, a request to forward to an unpublished channel:
* The node knows that the peer with the unpublished channel is the ultimate receiver of the payment.
* If a node receives from an unpublished channel, a request to forward to any channel:
* The node knows that the peer with the unpublished channel is the ultimate sender of the payment.
* This is a strong privacy loss: ultimate senders otherwise have strong privacy if they did not make the first hop via an unpublished channel, whereas ultimate receivers can already be guessed at by looking at the remaining timelock.
The worst case is the below:
* If a node receives from an unpublished channel, a request to forward to an unpublished channel:
* The node knows who the ultimate sender and receiver are!
Less powerfully, an entity that controls *multiple* nodes on the network, and which encourages other nodes to make unpublished channels with their nodes, can monitor the activities of those nodes on the Lightning Network:
* If one of its nodes receives from an unpublished channel, a request to forward to any channel, and a short while later, another of its nodes receives from any channel, a similar smaller amount and cltv-delta, a request to forward to an unpublished channel:
* The entity has a good chance of correlating who the ultimate sender and receiver are!
* In the current network, without payment decorrelation, the same hash being used on both is definite proof that they are indeed the ultimate sender and receiver.
* Worse than with the lack of payment decorrelation, is that the entity now knows exactly who the ultimate payer and receiver are, and not have to guess that they are nearby their nodes (which would be the case if it sees the same hash, but the channels involved are all published channels).
Thus, it is not privacy-safe, under the current specs, to use unpublished channels, if there is the possibility of one or more entities controlling multiple nodes on the network that have unpublished channels.
Breaking the Axiom of Terminus
The axiom of terminus leads to a trivial way for entities controlling large amounts of Bitcoin (and thus capable of viably running multiple nodes) to closely monitor participants in the network, especially if they have significant numbers of unpublished channels.
Thus, we must have methods of breaking the axiom of terminus, in order to prevent analysis of payments on the Lightning Network.
Invoice `r` Field
This is the sole existing way to break the axiom of terminus under the current spec.
Suppose as in our example, that BC is unpublished but AB and CD are published.
If A ever needs to pay C, then C will reveal the existence of BC to A via the invoice `r` field.
Subsequently, if A then needs to pay D, A now has enough information to route a payment to D via the BC channel.
However, this is sadly insufficient.
Invoice `r` fields only provide feerates in *one* direction.
Unfortunately channels have different feerates in both directions.
Thus A cannot itself reveal the BC channel to D via its own invoice `r` field, since what A knows is the direction B-to-C of the BC channel, but what D needs to route to A, is the direction C-to-B of the BC channel.
Of greater note is that nodes that have *only* unpublished channels, *cannot break the axiom of terminus at all*.
This is because such nodes can only provide their incoming feerates in invoice `r` fields.
But forwarding requires that an incoming followed by an outgoing channel direction, thus nodes with only unpublished channels will be unable to break the axiom of terminus even by invoice `r` fields.
Completely unpublished channels, as I have demonstrated, are simply bad for privacy, due to the axiom of terminus.
However, it should be possible to locally publish such channels.
I believe Rene Pickhardt has been planning to propose such a local publication of channels for the purpose of assisting JIT Routing.
I propose then the below new messages:
1. type: TBD odd (`request_local_unpublished_channels`)
* ['u16`: `max_local_unpublished_channels`]
Causes the receiver of this message to reply with `respond_local_unpublished_channels`.
* MUST NOT send this message if it does not have a channel with the receiver.
* MUST fail the connection if it receives this message when it does not have a channel with the sender.
1. type: TBD even (`respond_local_unpublished_channels`)
* [`u16` : `num_local_unpublished_channels`]
* [`num_local_unpublished_channels * u64` : `short_channel_ids`]
* [`num_local_unpublished_channels * u32` : `fee_base_satoshis_0`]
* [`num_local_unpublished_channels * u32` : `fee_proportional_millionths_0`]
* [`num_local_unpublished_channels * u32` : `cltv_delta_0`]
* [`num_local_unpublished_channels * u32` : `fee_base_satoshis_1`]
* [`num_local_unpublished_channels * u32` : `fee_proportional_millionths_1`]
* [`num_local_unpublished_channels * u32` : `cltv_delta_1`]
* [`num_local_unpublished_channels * 33` : `nodeids`]
Provides data about local unpublished channels.
These are channels that are directly connected to the sender node, and where the counterparty is the corresponding index in `nodeids`.
* MUST NOT send this message unless the receiver already sent a `request_local_unpublished_channels`.
* MUST NOT duplicate any peer node IDs.
* If the sender has more than one unpublished channel with a particular peer, it SHOULD select one channel as a representative of all the channels.
* MUST NOT send more than `max_local_unpublished_channels` channels.
* MUST NOT send a published channel.
* if it receives this message unsolicited, MAY fail the connection.
* if a node ID is duplicated, SHOULD fail the connection.
* if more than `max_local_unpublished_channels` is contained, SHOULD fail the connection.
* if it has seen a `channel_announcement` of a channel listed in this message, SHOULD fail the connection.
### Operation and Usage
A node might request its peers to provide information about local unpublished channels in order to augment its routemap for normal payment usages.
This allows the channels to break the axiom of terminus and let an unpublished channel be used in the middle of a routemap.
However, because it can only ask locally, the axiom of terminus is simply deferred by one hop.
Now, the unpublished channel may be at most one hop away from the ultimate source or ultimate receiver of the payment.
Further, JIT Routing might trigger this dynamically when it is unable to find a short rebalancing path.
This allows for more opportunities to rebalance.
More information about the Lightning-dev