2

Imagine Alice wants to send 0.5 btc to Bob. They both open channels with Carol, a relay node that has no money. They create single funded channels each of 1 btc.

Now Alice updates her channel to be 0.5 to her and 0.5 to Carol (nevermind LN fees for now).

To relay this 0.5 to Bob, Carol (the relay node) needs to update her channel with Bob to be also be 0.5 her and 0.5 Bob. But she doesn't have any money on her side to do this. All the money is on Bob's side -- as I said earlier, Carol doesn't have any money.

What's the workaround for this? Do relay nodes need to have money to relay transactions?

4

No, there is no work around for this. If a channel's balance is completely allocated to one side, the channel can only be used to move funds in one direction. Additionally, a channel whose balance is shifted completely to one side is vulnerable to the broadcast of a previous channel state as there are no funds to be lost for the attacker. This does not apply to channels that are unilaterally funded, since no previous channel state exists in that case.

It is therefore not recommended to exhaust a channel completely in one direction. To maintain liquidity in both directions, proposed approaches are to charge increased fees as channels get further out of balance, and to charge lower fees, possibly even negative fees, in the direction that moves a channel back towards equilibrium.

Routing algorithms that minimize the fee for a route would thus be incentivized to help rebalance routes along the path. Additionally, this means that cycles can exist in the graph that actually incur in sum a negative fee, which any member of that cycle could collect by initiating a payment to themselves along the cycle to the collective benefit.


Update: It follows an example for using a cycle to rebalance channels.

Take the three payment channels

Alice 0.8 : 0.2 Bob 
  Bob 0.7 : 0.3 Carol
Carol 0.9 : 0.1 Alice

Alice notices the cycle, and creates a three hop payment that pays 0.3 BTC to herself by route of Bob and Carol. She crafts the HTLC, and sends it to Bob, Bob accepts and forwards to Carol, Carol accepts and forwards to Alice. Alice executes the last hop, Carol the middle and Bob pulls in the locked funds from Alice resulting in more balanced channels for everyone.

Alice 0.5 : 0.5 Bob 
  Bob 0.4 : 0.6 Carol
Carol 0.6 : 0.4 Alice

Note that Bob and Carol do not know that Alice paid to herself as they can each only see the next hop and previous hop in the contract chain.

  • Would you care helping me understand how this "cycle" would work? I guess also routing algorithms will perhaps take longer paths (rather than short ones) in order to rebalance some channels, for the health of the network as a whole? – Luca Matteis Jan 1 '18 at 19:56
  • If node operators offer a negative fee to use their payment channel in a specific direction an algorithm that finds the cheapest route would prefer using such channels. – Murch Jan 2 '18 at 17:17
  • 1
    @LucaMatteis: I've added an example. – Murch Jan 2 '18 at 17:26
  • Thanks @Murch, this is very useful! Does the current spec allow this rebalancing loop you described? Can it be used today with existing wallets like Zap? If it's not ready, any idea where can we monitor progress. This sounds like a really needed part of the protocol. – kim0 Feb 15 '18 at 13:57

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.