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
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Reply via email to