[Lightning-dev] Research on proactive fee free channel rebalancing in the friend of a friend network / and roadmap for a protocol extension

[ZmnSCPxj]

Good morning Rene,

What no JIT-routing?


> # Roadmap for BOLT 14 (Fee free Rebalancing Transport):
>
> If no strong objections exist I would try to extend the BOLTs with the following to be able to implement the rebalancing algorithm across the network (as with JIT routing nodes can already opt to implement the algorithm for themselves but this is probably not to useful from an economic point of view).
>
> * BOLT 07: a new gossip query and reply `query_want_rebalance_channel_ids` / `reply_want_rebalance_channel_ids` to ask channel partners on which of their channels they want inbound / outbound liquidity. The query could already include an optional offer how much the node initiating the rebalancing operation is willing to offer while the reply could have an optional offer field stating how much they nodes are willing to rebalance (as the paper shows nodes might not have consensus about the amount and the algorithm currently works by agreeing on the lowest value). Of course this extension needs some protection against probing attacks to protect the privacy of nodes.
> * BOLT 14: (Fee Free Rebalancing Transport) While it seems tempting to Reuse BOLT04 with a different realm that omits fees for the rebalancing cycles (which nodes would have to accept then) this seems impossible as the onions are not public and nodes could not verify that this is really a rebalancing operation and not a payment which tries to "steel" fees. While we might be able to extend BOLT 02 with a new message that transports a "rebalancing" onion together with the keys for every envelop so that everyone can verify that in fact this fee free onion is a rebalancing cycle it seems plausible to have an open tansport for fee free rebalancing to start with. We could also make it a feature flag and allow nodes to signal if they support fee free rebalancing. I guess for backwards compatebility this should be done in any case.
> * One problem / attack vector with circular fee free payments that I see is that if Alice wants to pay David she could initiate a rebalancing onion: A --> B --> C --> D --> A with the paymenthash that David has created in an invoice. David would just not set up the final HTLC from him to Alice as he wanted to receive money from Alice. As far as I see this attack would only be possible if Alice and David have a channel which they could have used for the payment right away. Not using that channel is effectively a rebalancing operation which is exactly why we allow such a protocol. This means that the channel between Alice and David has to be public to allow for a fee free operation. Otherwhise I could always claim to have a private channel if I wanted to pay someone without fees.
> Still this allows two people who have a public channel to spam out HTLCs which settle at no cost. However - according to my research - nodes along the cycle only participate if that was beneficial for them. Also since these rebalancing cycles are open and transparent they could be blocked if nodes feel they are being abused.
>
> While the extension of BOLT 07 seems rather simple and straight forward. BOLT 14 (I like the fact, that it is actually 4 + 10 ) might be more controversial. Especially for that I would love to have some feedback before I start to spec this out.

Definitely.
In particular I am wary of making the rebalance different from payments.
We should consider always that there will be nodes whose only purpose in life is to monitor the activities of other people.

The fact that current rebalances are indistinguishable (or at least hard to distinguish) from normal payments is helpful for privacy: it makes it harder for surveillors, since they have to filter out rebalance attempts from actual real payments.
Splitting out rebalances from payments breaks this privacy advantage.

I suggest rather that:

* Add a local-scope broadcast "I provisionally allow routing via this channel-direction without fees; this offer is valid up to blockheight B".
  * Add a secret in this broadcast ("here is the claimcode: ZmnSCPxj").
* Hide rebalances in the current onion format; just do not decrement the outgoing value from the incoming value (i.e. 0 fee).
  * Add the secret in the broadcast in a new even TLV.

I think it is not necessary for a node to directly know if an HTLC to be forwarded is a "real" payment or a "rebalance".
In particular:

* The node will only offer a fee-free rebalance if its own channel is imbalanced in that direction.
* It does not matter if the payment is "real" or "rebalance": it will change the channel to be balanced anyway, which is already a win.
* Regardless of whether the payment is "real" or "rebalance", if the payment will not cause the channel to be balanced (for example, somebody else managed to already balance that channel, *or* the payment is too big and causes the channel to be imbalanced in the reverse direction instead), then the node should reject the payment anyway if the fee is 0.

Thus, I suggest instead:

* Define a new message for local broadcast of channels that would be nice to balance.
* Add a new TLV for onions that includes a secret from the previous message.
* Add a new onion failure code that includes a proposed amount.
  * The sender MUST NOT send this failure code if the onion entry for that node does not contain the previous TLV.


Regards,
ZmnSCPxj