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

Create a transaction sending more money into the main multi-sig account
Create a refund transaction for the amount in that transaction, using that specific transaction's output as the input to the refund transaction
Send the refund transaction to the channel partner for signature
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)? 

user24974: 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.

user82931: There is a way to increase the capacity of the payment channel. Dynamic Channel Deposit and Withdraw for Lightning Networks

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.

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


5254: <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>
 24974: <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>
 82931: <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.stack.imgur.com/IVyyc.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/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>
