7

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

3

3 Answers 3

2

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

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

Yes, this is called a submarine swap.

From the glossary of Mastering the Lightning Network:

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:

6
  • 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
    Dec 21, 2023 at 22:52
  • @OptOut Yeah, maybe. But it does increase the sending (or receiving) capacity.
    – Geremia
    Dec 22, 2023 at 0:43
  • 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
    Dec 23, 2023 at 6:10
  • Actually, I've learned that the way to do what I'm asking is called a splice (splice in or splice out).
    – B T
    Dec 29, 2023 at 21:50
  • 1
    @Geremia I don't believe so. Looks like Eclair, c lightning, and Phoenix wallet have implemented splicing tho. bitcoinops.org/en/topics/splicing
    – B T
    Jan 3 at 19:29

Your Answer

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

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