<p>There is a way to increase the capacity of the payment channel. <a href="https://github.com/litexnetwork/papers/blob/master/FundCasc.pdf" rel="nofollow noreferrer">Dynamic Channel Deposit and Withdraw for Lightning Networks</a>
<a href="https://i.sstatic.net/IVyyc.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/IVyyc.png" alt="The FundCasc Splice-in"></a></p>

<p>If A want to add 0.5 BTC to the channel, he can propose to create a new funding transaction which spent the old funding and another UTXO from A. The new Funding transaction can be created by following steps.</p>

<ol>
<li>Creating a new Funding Transaction</li>
<li>Creating a pair of new Commitment Transactions (C2a and C2b), containing the corresponding RD2a and RD2b</li>
<li>Signing the new Commitment Transactions</li>
<li>Exchanging signatures for new Commitment Transactions</li>
<li>Signing a new Funding Transaction</li>
<li>Exchanging signatures for the new Funding Transaction</li>
<li>Broadcasting the new Funding Transaction</li>
</ol>

CC BY-SA 4.0
2018-05-09T14:41:43.590Z
2018-05-09T14:41:43.590Z
johnson zhang
<p>This proposal (or similar solutions requiring an on-chain transaction) would move funds in the channel back from user B (Bob) to user A (Alice).  This is useful, because a channel may have more traffic in one direction, meaning at some point no more transactions can flow in that direction.  A single on-chain transaction is preferable to the two that would be required to close and then reopen the channel.</p>

<p>However, to say that this is adding money to the channel is incorrect.  That is <em>not</em> possible without reopening the channel.  Let me illustrate:</p>

<p>Let's say that Alice and Bob each contribute 0.5 BTC to opening transaction of the channel.  This means there is a total of 1 BTC in the channel to begin with:</p>

<pre><code>Alice (0.5) ================== (0.5) Bob
</code></pre>

<p>After some time, more traffic has gone from Alice to Bob than from Bob to Alice.  This means that Alice's side of the channel is depleted, but Bob's still has plenty of funds:</p>

<pre><code>Alice (0.05) ================== (0.95) Bob
</code></pre>

<p>Now, let's say that Alice sends Bob an on-chain transaction (not over the channel), to essentially buy back some of her BTC:</p>

<pre><code>                  on-chain
              -----(0.45)----&gt;
  +---&gt;---&gt;---&gt;---&gt;---&gt;---&gt;---&gt;---&gt;---+
  |                                   |
Alice (0.5) ================== (0.5) Bob
              &lt;----(0.45)-----
                 over-channel
</code></pre>

<p>This works to rebalance the channel, but it does not add any funds to it.  There is still only 1 BTC in the channel.  The funds from the on-chain transaction goes into Bob's personal Bitcoin wallet, and is not on the lightning network.  It does nothing to increase the size of the channel.</p>

<p>This technique may prove to be useful to prevent channels from becoming unbalanced, so I don't mean to imply that this is not useful.  It is also important to note that a similar technique could work by using an alternate lightning route from Alice to Bob:</p>

<pre><code>            routed through Charlie
              -----(0.45)----&gt;
  ===============(Charlie)=============
  |                                   |
Alice (0.5) ================== (0.5) Bob
              &lt;----(0.45)-----
                 over-channel
</code></pre>

<p>This would eliminate the need for an on-chain transaction.  However, if an alternative route exists, it would probably make more sense to leave the Alice-Bob chain unbalanced, and simply route payments along the Alice-Charlie-Bob route.</p>

CC BY-SA 3.0
2017-08-10T20:55:55.167Z
I wasn't suggesting that Alice ever send Bob btc directly, so I think you misunderstood me. I was proposing that Alice send more btc to the shared multi-sig address that keeps the channel's funds. Doesn't this actually add funds to the channel? Also, I don't see anywhere in your answer explaining why adding funds is "not possible", just an explanation of techniques that don't perform that behavior. Do the proposals in the linuxfoundation.org thread not work?
B T
CC BY-SA 3.0
2017-08-10T21:07:08.923Z
Sorry for misunderstanding, but I don't think it changes the answer.  Just because you re-use an address, does not mean you are increasing the funds of the original UTXOs.  The smart contracts work on UTXOs, not addresses.  A different transaction to the same address is still a different UTXO, and one that is not involved in the original contract.  All this stuff is still new and just being figured out, meaning that even the devs don't know everything.  Perhaps you should email the participants of the mailing list, if you want to know current direction and capabilities.
Jestin
CC BY-SA 3.0
2017-08-10T21:09:40.303Z
Ok, thanks for the discussion! Sounds like the keyword being talked about with regard to this is "reanchoring"
B T
CC BY-SA 3.0
2017-08-10T21:11:36.353Z
If you find a better answer in your research, be sure to post it here.  It would be nice for Bitcoin SE to be the place for all the best questions and answers!
Jestin
CC BY-SA 3.0
2017-08-10T21:12:47.077Z
Will do. It sounds like the reanchoring stuff effectively solves this, and other, problems. If I manage to gain enough understanding to properly explain it, I'll post an answer.
B T
CC BY-SA 3.0
2018-02-16T12:51:47.677Z
Wonder if both Alice and Bob could you two addresses owned by me, and thus I am always able to balance my own channels to be able to send/receive on them?
kim0
CC BY-SA 3.0
2017-08-10T20:39:04.763Z
2017-08-10T20:39:04.763Z
Jestin
<p>Yes, this is called a submarine swap.</p>
<p>From <a href="https://github.com/lnbook/lnbook/blob/develop/glossary.asciidoc" rel="nofollow noreferrer">the glossary</a> of <a href="https://isidore.co/calibre/#panel=book_details&amp;book_id=8351" rel="nofollow noreferrer"><em>Mastering the Lightning Network</em></a>:</p>
<blockquote>
<p><em><strong>submarine swap</strong></em>
<br>A submarine swap is a trustless atomic swap between on-chain Bitcoin addresses and off-chain Lightning Network payments. Just as LN payments use HTLCs that make the final claim on funds conditional on the recipient revealing a secret (hash preimage), submarine swaps use the same mechanism to transfer funds across the on-chain/off-chain barrier with minimal trust. Reverse submarine swaps allow swaps in the opposite direction, from an off-chain LN payment to an on-chain Bitcoin address.</p>
</blockquote>
<p>Here's what the dialog box for it looks like in <a href="https://electrum.org/" rel="nofollow noreferrer">Electrum</a>:</p>
<p><a href="https://electrum.org/" rel="nofollow noreferrer"><img src="https://i.sstatic.net/9lCxt.png" width="500"/></a></p>

CC BY-SA 4.0
2023-12-21T22:52:58.083Z
Using submarine swap it's not possible to change the capacity of the channel. I think by 'adding funds' the original question meant 'increasing the channel capacity'.
OptOut
CC BY-SA 4.0
2023-12-22T00:43:06.497Z
@OptOut Yeah, maybe. But it does increase the sending (or receiving) capacity.
Geremia
CC BY-SA 4.0
2023-12-23T06:10:53.010Z
The LN part of the submarine swap is a regular incoming LN payment, and a payment does change the _balances_ -- increase the local balance and decrease the remote one --, but it does not affect the channel capacity -- defined by the size of the funding transaction. The channel capacity cannot be changed without changing the funding transaction.
OptOut
CC BY-SA 4.0
2023-12-29T21:50:27.900Z
Actually, I've learned that the way to do what I'm asking is called a splice (splice in or splice out).
B T
CC BY-SA 4.0
2023-12-29T23:24:15.010Z
@BT Can Electrum do splices?
Geremia
CC BY-SA 4.0
2024-01-03T19:29:30.380Z
@Geremia I don't believe so. Looks like Eclair, c lightning, and Phoenix wallet have implemented splicing tho. https://bitcoinops.org/en/topics/splicing/
B T
CC BY-SA 4.0
2023-12-21T20:04:53.893Z
2023-12-21T20:04:53.893Z
Geremia
<p>I would think that user A on a channel should be able to add bitcoins to a channel using the following steps:</p>

<ol>
<li>Create a transaction sending more money into the main multi-sig account</li>
<li>Create a refund transaction for the amount in that transaction, using that specific transaction's output as the input to the refund transaction</li>
<li>Send the refund transaction to the channel partner for signature</li>
<li>Post the transaction created in (1) to the blockchain</li>
</ol>

<p>Are there problems with this method? Is it possible to "top up" a LN channel in this (or any) way, using only one additional on-chain transaction (rather than the two you'd need to close and reopen the channel)? </p>

CC BY-SA 3.0
2017-08-10T19:45:46.783Z
Note I just found this, tho the proposed mechanism seems different: https://lists.linuxfoundation.org/pipermail/lightning-dev/2017-May/000692.html
B T
CC BY-SA 3.0
2017-08-10T20:15:24.653Z
@B T, there is nothing wrong with answering your own question.  The link you found looks like a pretty good solution to your original question, so long as you provide a summary and some context in the answer.  I suggest you write up an answer, in case others have this same question.
Jestin
CC BY-SA 3.0
2017-08-10T20:42:17.767Z
It's also worth reading the follow-up email to the one you mentioned:  https://lists.linuxfoundation.org/pipermail/lightning-dev/2017-May/000696.html  In fact, the whole thread is worth a read!
Jestin
<lightning-network><ln-splicing>
Is it possible to add funds to an already-open lightning network channel?
B T
# Is it possible to add funds to an already-open lightning network channel?

(Asked by: username_0 on 2017-08-10)

I would think that user A on a channel should be able to add bitcoins to a channel using the following steps:

1. Create a transaction sending more money into the main multi-sig account
2. Create a refund transaction for the amount in that transaction, using that specific transaction's output as the input to the refund transaction
3. Send the refund transaction to the channel partner for signature
4. Post the transaction created in (1) to the blockchain

Are there problems with this method? Is it possible to "top up" a LN channel in this (or any) way, using only one additional on-chain transaction (rather than the two you'd need to close and reopen the channel)?

**Tags:** lightning-network, ln-splicing

> **Comments:**
> **username_0**: Note I just found this, tho the proposed mechanism seems different: https://lists.linuxfoundation.org/pipermail/lightning-dev/2017-May/000692.html  
> **username_1**: @username_0, there is nothing wrong with answering your own question.  The link you found looks like a pretty good solution to your original question, so long as you provide a summary and some context in the answer.  I suggest you write up an answer, in case others have this same question.  
> **username_1**: It's also worth reading the follow-up email to the one you mentioned:  https://lists.linuxfoundation.org/pipermail/lightning-dev/2017-May/000696.html  In fact, the whole thread is worth a read!  

---

## 3 answers

### Answer by username_2 on 2018-05-09. Score: 2

There is a way to increase the capacity of the payment channel. [Dynamic Channel Deposit and Withdraw for Lightning Networks](https://github.com/litexnetwork/papers/blob/master/FundCasc.pdf)
[![The FundCasc Splice-in](https://i.sstatic.net/IVyyc.png)](https://i.sstatic.net/IVyyc.png)

If A want to add 0.5 BTC to the channel, he can propose to create a new funding transaction which spent the old funding and another UTXO from A. The new Funding transaction can be created by following steps.

1. Creating a new Funding Transaction
2. Creating a pair of new Commitment Transactions (C2a and C2b), containing the corresponding RD2a and RD2b
3. Signing the new Commitment Transactions
4. Exchanging signatures for new Commitment Transactions
5. Signing a new Funding Transaction
6. Exchanging signatures for the new Funding Transaction
7. Broadcasting the new Funding Transaction


---

### Answer by username_1 on 2017-08-10. Score: 1

This proposal (or similar solutions requiring an on-chain transaction) would move funds in the channel back from user B (Bob) to user A (Alice). This is useful, because a channel may have more traffic in one direction, meaning at some point no more transactions can flow in that direction. A single on-chain transaction is preferable to the two that would be required to close and then reopen the channel.

However, to say that this is adding money to the channel is incorrect. That is *not* possible without reopening the channel. Let me illustrate:

Let's say that Alice and Bob each contribute 0.5 BTC to opening transaction of the channel. This means there is a total of 1 BTC in the channel to begin with:

```
Alice (0.5) ================== (0.5) Bob

```

After some time, more traffic has gone from Alice to Bob than from Bob to Alice. This means that Alice's side of the channel is depleted, but Bob's still has plenty of funds:

```
Alice (0.05) ================== (0.95) Bob

```

Now, let's say that Alice sends Bob an on-chain transaction (not over the channel), to essentially buy back some of her BTC:

```
                  on-chain
              -----(0.45)---->
  +--->--->--->--->--->--->--->--->---+
  |                                   |
Alice (0.5) ================== (0.5) Bob
              <----(0.45)-----
                 over-channel

```

This works to rebalance the channel, but it does not add any funds to it. There is still only 1 BTC in the channel. The funds from the on-chain transaction goes into Bob's personal Bitcoin wallet, and is not on the lightning network. It does nothing to increase the size of the channel.

This technique may prove to be useful to prevent channels from becoming unbalanced, so I don't mean to imply that this is not useful. It is also important to note that a similar technique could work by using an alternate lightning route from Alice to Bob:

```
            routed through Charlie
              -----(0.45)---->
  ===============(Charlie)=============
  |                                   |
Alice (0.5) ================== (0.5) Bob
              <----(0.45)-----
                 over-channel

```

This would eliminate the need for an on-chain transaction. However, if an alternative route exists, it would probably make more sense to leave the Alice-Bob chain unbalanced, and simply route payments along the Alice-Charlie-Bob route.

> **Comments:**
> **username_0**: I wasn't suggesting that Alice ever send Bob btc directly, so I think you misunderstood me. I was proposing that Alice send more btc to the shared multi-sig address that keeps the channel's funds. Doesn't this actually add funds to the channel? Also, I don't see anywhere in your answer explaining why adding funds is "not possible", just an explanation of techniques that don't perform that behavior. Do the proposals in the linuxfoundation.org thread not work?  
> **username_1**: Sorry for misunderstanding, but I don't think it changes the answer.  Just because you re-use an address, does not mean you are increasing the funds of the original UTXOs.  The smart contracts work on UTXOs, not addresses.  A different transaction to the same address is still a different UTXO, and one that is not involved in the original contract.  All this stuff is still new and just being figured out, meaning that even the devs don't know everything.  Perhaps you should email the participants of the mailing list, if you want to know current direction and capabilities.  
> **username_0**: Ok, thanks for the discussion! Sounds like the keyword being talked about with regard to this is "reanchoring"  
> **username_1**: If you find a better answer in your research, be sure to post it here.  It would be nice for Bitcoin SE to be the place for all the best questions and answers!  
> **username_0**: Will do. It sounds like the reanchoring stuff effectively solves this, and other, problems. If I manage to gain enough understanding to properly explain it, I'll post an answer.  
> **username_3**: Wonder if both Alice and Bob could you two addresses owned by me, and thus I am always able to balance my own channels to be able to send/receive on them?  

---

### Answer by username_4 on 2023-12-21. Score: -1

Yes, this is called a submarine swap.

From [the glossary](https://github.com/lnbook/lnbook/blob/develop/glossary.asciidoc) of [*Mastering the Lightning Network*](https://isidore.co/calibre/#panel=book_details&book_id=8351):

> ***submarine swap***
>   
> A submarine swap is a trustless atomic swap between on-chain Bitcoin addresses and off-chain Lightning Network payments. Just as LN payments use HTLCs that make the final claim on funds conditional on the recipient revealing a secret (hash preimage), submarine swaps use the same mechanism to transfer funds across the on-chain/off-chain barrier with minimal trust. Reverse submarine swaps allow swaps in the opposite direction, from an off-chain LN payment to an on-chain Bitcoin address.

Here's what the dialog box for it looks like in [Electrum](https://electrum.org/):

[![](https://i.sstatic.net/9lCxt.png)](https://electrum.org/)

> **Comments:**
> **username_5**: Using submarine swap it's not possible to change the capacity of the channel. I think by 'adding funds' the original question meant 'increasing the channel capacity'.  
> **username_4**: @username_5 Yeah, maybe. But it does increase the sending (or receiving) capacity.  
> **username_5**: The LN part of the submarine swap is a regular incoming LN payment, and a payment does change the _balances_ -- increase the local balance and decrease the remote one --, but it does not affect the channel capacity -- defined by the size of the funding transaction. The channel capacity cannot be changed without changing the funding transaction.  
> **username_0**: Actually, I've learned that the way to do what I'm asking is called a splice (splice in or splice out).  
> **username_4**: @BT Can Electrum do splices?  
> **username_0**: @username_4 I don't believe so. Looks like Eclair, c lightning, and Phoenix wallet have implemented splicing tho. https://bitcoinops.org/en/topics/splicing/  

---

