<p>As <a href="https://bitcoin.stackexchange.com/a/114857/5406">mentioned by Antoine</a>, Alice and Bob could make a transaction to close the channel, Alice could use her payout to make the payment, and then Alice could use the change of that payment reopen the channel with a lower capacity. Note that unless they collaborate to use both Alice's and Bob's inputs, the new channel would also lack the Bob's prior balance. The same could also be achieved more efficiently by <em>splicing out</em> the payment. Alice and Bob would then collaborate to spend the funding output to create a transaction with two outputs where one is the payment Alice wants to make, and the other output is a new channel's funding output. This would save a transaction reducing the overall blockspace footprint and channel-downtime as well as result in a new channel with higher balance.</p>
<p>Another option would be for Alice to pay someone else on the Lightning Network to execute an onchain transaction for her. If e.g. Carol who has a channel with Bob were to offer this service, and Alice would send a ₿0.5 payment through Bob to Carol (plus maybe a fee), who would then make the expected onchain payment. By creative use of HTLCs, this payment could even be linked with the payment on LN so that the whole chain executes atomically. Instead of reducing the channel capacity, this would shift some of Bob's Lightning balance from his channel with Carol to his channel with Alice (and reduce Alice's balance, while increasing Carol's). This layer-traversing payment type is referred to as a &quot;submarine swap&quot;.</p>

CC BY-SA 4.0
2023-01-14T18:07:33.657Z
Yeah but by using splicing, we cannot create a new channel with greater channel capacity than the parent channel, right?
Arjun Reddy
CC BY-SA 4.0
2023-01-14T18:09:08.097Z
With splice outs you can make a payment from the channel and immediately create a new smaller channel. With a splice in, you can add another input and create a bigger channel. If the input is unilaterally controlled, you need to wait for confirmations again, though.
Murch
CC BY-SA 4.0
2023-01-14T18:12:02.297Z
I didn't get properly this term "If the input is unilaterally controlled, you need to wait for confirmations again". What does this mean? Like how an input is unilaterally controlled
Arjun Reddy
CC BY-SA 4.0
2023-01-14T20:41:57.097Z
If one of the two channel partners is contributing the funds by themselves, they would be able to create a conflicting transaction that could cancel the channel open. One way around that would be to put the funds into a 2-of-2 with the channel partner first and wait for confirmations while the channel is still operating, so that when the additional funds are spliced in, both parties know that the source of additional funds cannot be spent in another transaction by the other one alone.
Murch
CC BY-SA 4.0
2023-01-15T07:16:08.693Z
So, here for 
1.)getting confirmations for 2-of-2 channel is 1 transaction
2.) settlement of balance, closing the parent channel  and opening new channel is other transaction,
Which is 2 transactions required for splice-in, but how is this efficient when compared to First settling and closing channel ->1 transaction and then 
2.) opening new channel -> 1 transaction
This method also takes 2 transaction
How is splice-in method efficient when compared to normal closing and opening channel?
Arjun Reddy
CC BY-SA 4.0
2023-01-15T20:29:59.510Z
The closing transaction can create the new channel immediately instead of paying out the owners. The staging is optional if you do not want to interrupt channel operation at all, otherwise it can all be done in one tx.
Murch
CC BY-SA 4.0
2022-08-12T15:36:27.290Z
2022-08-12T18:42:53.563Z
2022-08-12T18:42:53.563Z
Murch
<p>If you mean decreasing the capacity of the channel to 1.5BTC in order to withdraw 0.5BTC onchain, it is possible in theory but not yet part of the Lightning Network protocol nor its implementations. That's called <a href="https://bitcoin.stackexchange.com/a/114670/101498">splice</a>-out.</p>
<p>Of course, you can always do that today by closing the 2BTC channel and re-opening a 1.5BTC one.</p>

CC BY-SA 4.0
2022-08-12T08:02:31.050Z
2022-08-12T08:02:31.050Z
Antoine Poinsot
<p>Let's say Alice and Bob have a 2BTC channel together. Both have a balance of 1BTC. Can Alice withdraw part of her balance (say, 0.5BTC) from the channel?</p>

CC BY-SA 4.0
2022-08-12T08:05:59.207Z
I've edited your question to, in my view, make it clearer more to the point. I'm not entirely sure it was what you intended so of course feel free to roll back.
Antoine Poinsot
<lightning-network><balance><channels><ln-channel-balance-management><ln-splicing>
Lightning channel decrease capacity
Arjun Reddy
# Lightning channel decrease capacity

(Asked by: username_0 on 2022-08-12)

Let's say Alice and Bob have a 2BTC channel together. Both have a balance of 1BTC. Can Alice withdraw part of her balance (say, 0.5BTC) from the channel?

**Tags:** lightning-network, balance, channels, ln-channel-balance-management, ln-splicing

> **Comments:**
> **username_1**: I've edited your question to, in my view, make it clearer more to the point. I'm not entirely sure it was what you intended so of course feel free to roll back.  

---

## 2 answers

### Answer by username_2 on 2022-08-12. Score: 5

As [mentioned by username_1](https://bitcoin.stackexchange.com/a/114857/5406), Alice and Bob could make a transaction to close the channel, Alice could use her payout to make the payment, and then Alice could use the change of that payment reopen the channel with a lower capacity. Note that unless they collaborate to use both Alice's and Bob's inputs, the new channel would also lack the Bob's prior balance. The same could also be achieved more efficiently by *splicing out* the payment. Alice and Bob would then collaborate to spend the funding output to create a transaction with two outputs where one is the payment Alice wants to make, and the other output is a new channel's funding output. This would save a transaction reducing the overall blockspace footprint and channel-downtime as well as result in a new channel with higher balance.

Another option would be for Alice to pay someone else on the Lightning Network to execute an onchain transaction for her. If e.g. Carol who has a channel with Bob were to offer this service, and Alice would send a ₿0.5 payment through Bob to Carol (plus maybe a fee), who would then make the expected onchain payment. By creative use of HTLCs, this payment could even be linked with the payment on LN so that the whole chain executes atomically. Instead of reducing the channel capacity, this would shift some of Bob's Lightning balance from his channel with Carol to his channel with Alice (and reduce Alice's balance, while increasing Carol's). This layer-traversing payment type is referred to as a "submarine swap".

> **Comments:**
> **username_0**: Yeah but by using splicing, we cannot create a new channel with greater channel capacity than the parent channel, right?  
> **username_2**: With splice outs you can make a payment from the channel and immediately create a new smaller channel. With a splice in, you can add another input and create a bigger channel. If the input is unilaterally controlled, you need to wait for confirmations again, though.  
> **username_0**: I didn't get properly this term "If the input is unilaterally controlled, you need to wait for confirmations again". What does this mean? Like how an input is unilaterally controlled  
> **username_2**: If one of the two channel partners is contributing the funds by themselves, they would be able to create a conflicting transaction that could cancel the channel open. One way around that would be to put the funds into a 2-of-2 with the channel partner first and wait for confirmations while the channel is still operating, so that when the additional funds are spliced in, both parties know that the source of additional funds cannot be spent in another transaction by the other one alone.  
> **username_0**: So, here for  1.)getting confirmations for 2-of-2 channel is 1 transaction 2.) settlement of balance, closing the parent channel  and opening new channel is other transaction, Which is 2 transactions required for splice-in, but how is this efficient when compared to First settling and closing channel ->1 transaction and then  2.) opening new channel -> 1 transaction This method also takes 2 transaction How is splice-in method efficient when compared to normal closing and opening channel?  
> **username_2**: The closing transaction can create the new channel immediately instead of paying out the owners. The staging is optional if you do not want to interrupt channel operation at all, otherwise it can all be done in one tx.  

---

### Answer by username_1 on 2022-08-12. Score: 4

If you mean decreasing the capacity of the channel to 1.5BTC in order to withdraw 0.5BTC onchain, it is possible in theory but not yet part of the Lightning Network protocol nor its implementations. That's called [splice](https://bitcoin.stackexchange.com/a/114670/101498)-out.

Of course, you can always do that today by closing the 2BTC channel and re-opening a 1.5BTC one.


---

