<p>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.</p>

<p>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.</p>

<p>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.</p>

<hr>

<p>Update: It follows an example for using a cycle to rebalance channels.</p>

<p>Take the three payment channels</p>

<pre><code>Alice 0.8 : 0.2 Bob 
  Bob 0.7 : 0.3 Carol
Carol 0.9 : 0.1 Alice
</code></pre>

<p>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.</p>

<pre><code>Alice 0.5 : 0.5 Bob 
  Bob 0.4 : 0.6 Carol
Carol 0.6 : 0.4 Alice
</code></pre>

<p>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.</p>

CC BY-SA 3.0
2018-01-01T19:56:26.123Z
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
CC BY-SA 3.0
2018-01-02T17:17:00.057Z
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
CC BY-SA 3.0
2018-01-02T17:26:49.440Z
@LucaMatteis: I've added an example.
Murch
CC BY-SA 3.0
2018-02-15T13:57:53.257Z
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
CC BY-SA 3.0
2018-01-01T06:19:16.193Z
2018-01-02T17:26:34.210Z
2018-01-02T17:26:34.210Z
Murch
<p>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.</p>

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

<p>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.</p>

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

<lightning-network><lightning-routing><ln-channel-balance-management>
Do relay nodes need to have money in order to relay transactions?
Luca Matteis
# Do relay nodes need to have money in order to relay transactions?

(Asked by: username_0 on 2017-12-27)

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?

**Tags:** lightning-network, lightning-routing, ln-channel-balance-management


---

## 1 answers

### Answer by username_1 on 2018-01-01. Score: 4 | Accepted answer

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.

> **Comments:**
> **username_0**: 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?  
> **username_1**: 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.  
> **username_1**: @username_0: I've added an example.  
> **username_2**: Thanks @username_1, 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.  

---

