6

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)?

Improve this question
3

2 Answers 2

Reset to default
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.

Improve this answer
6
  • 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
    Aug 10, 2017 at 20:55
  • 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
    Aug 10, 2017 at 21:07
  • Ok, thanks for the discussion! Sounds like the keyword being talked about with regard to this is "reanchoring"
    – B T
    Aug 10, 2017 at 21:09
  • 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
    Aug 10, 2017 at 21:11
  • 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
    Aug 10, 2017 at 21:12
1

There is a way to increase the capacity of the payment channel. Dynamic Channel Deposit and Withdraw for Lightning Networks The FundCasc Splice-in

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
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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