When opening a Lightning channel, the first transaction is always called a Commitment transaction, this holds many key pieces of information about the channel. One of the most important variables is the amount of funds committed to the channel by each member, currently this amount is fixed and can not be changed until the channel ends, to explain how this can cause trouble we will offer an example.

Bob buys coffee from the café every day, he used to pay in Bitcoin but now that Lightning is on the main net he made a channel with the café and pays every day with Lightning. One day Bob’s initial funds run out and he couldn’t get coffee that day without paying the hefty on-chain transaction fee, now what if Bob could “top up” his Lightning channel with more coins?

This is called Splicing, and it’s a new feature that is currently in the works for Lightning. Splicing makes both parties able to “top up” or “drain” Bitcoin from their channel without closing the channel or having to open a new one.

Last week, a formal proposal was suggested on the Lightning mailing list by developer Rusty Russell on how we can implement Splicing by “allowing a single splice at a time”. René Pickhardt proposed an alternate version which is less complex to implement but might end up more expensive as it could require more onchain transactions.

The latest revision to this proposal was made by ZmnSCPxj which goes like the this:

The protocol starts by both sides providing a list of spliced inputs that are either confirmed or on their mempool, they then generate the splicing transaction, sign the new commitment transaction of the opposing side and then sign the splicing transaction and broadcast the fully signed splicing transaction.

This process might fail if the splicing transaction becomes invalidated from the mempool, one side notices the invalidation and informs the other side that the slice has failed, the other side monitors its own mempool for the invalidation of the splice with a timeout. If this side detects the invalidation it drops the splice and reverts back to the old channel specifications, if not then it will publish the latest old commitment and the latest new commitment and consider the channel closed and track it as a unilateral close.

This proposal is still in its infancy stages, but this is great development work that will help Lightning expand even further.

You can follow the discussion here.

Below is the latest revision to the proposal by developer ZmnSCPxj.

Glossary
--------

Old funding output - the TXO that the channel uses pre-splice.  This must be a 
SegWit 2-of-2.

New funding output - the TXO that the channel will use post-splice.  This must 
be a SegWit 2-of-2.

Old commitment transaction - a Poon-Dryja-revocable commitment transaction that 
consumes the old funding output.

New commitment transaction - a Poon-Dryja-revocable commitment transaction that 
consumes the new funding output.

Spliced input - a TXO wholly controlled solely by one channel party, which is 
intended for splicing into the channel.  This must be SegWit.

Splicing transaction - a transaction that consumes the old funding output and 
one or more spliced inputs, and outputs the new funding output.

oldfunding --> [splicing]--> newfunding
                 /\
                 ||
    splicedin  ==++

Splice Preparation Protocol
---------------------------

1.  Both sides provide a list of spliced inputs.  They confirm that the 
transactions are either confirmed or on their mempool.
2.  Both sides maintain a separate pair of division of their money.  One pair 
is the amount of money that can be currently used during the splice, and is 
initialized to the current state of the channel (money-during-splice).  The 
other pair is the amount of money each has that will be added after the splice 
is confirmed (money-added-to-splice).
3.  Both sides generate (but do not provide signatures or broadcast) the 
splicing transaction.
4.  Both sides sign the new commitment transaction of the opposing side (which 
spends the new funding transaction of the splicing transaction).
5.  Both sides now sign the splicing transaction, providing signatures for 
their nominated spliced inputs, and broadcast the fully signed splicing 
transaction.

Operation During Splice
-----------------------

While the splicing transaction is not sufficiently confirmed but is validly in 
their mempool or confirmed lightly, the channel is in "currently splicing" mode 
and changes to commitment transactions can be changed only according to these 
rules:

1.  Both old commitment transactions and new commitment transactions are 
updated in parallel.
2.  Each side can only use money that is theirs during the splice 
(money-during-splice) to offer HTLCs.  They cannot use spliced-in money yet to 
offer HTLCs.

Failure Modes
-------------

If the splicing transaction becomes invalidated from the mempool, and was not 
confirmed/included in the block, then the splice has failed.  Both sides should 
inform this splice failure to the other.

1.  If any old commitment transaction was spent to invalidate the splice 
transaction, then the channel has closed and both sides drop to tracking the 
channel closure as unilateral close.
2.  Otherwise, the splicing transaction became invalidated either due to a 
spend of any spliced input, or by invalidation of spliced input via transaction 
replacement (RBF).  In this case, the protocol moves to splice failure.

Splice Failure
--------------

1.  One side notices the splice failure and claims that the splice has failed.
2.  The other side monitors its own mempool for invalidation of the splicing 
transaction, with a timeout.
3.  If the other side also notices the splice failure, then both sides can drop 
the (money-added-to-splice) and revert back to the pre-splice channel.  Spliced 
inputs should be considered by their owner to be spendable again for other 
onchain purposes.
3.  Otherwise if the other side times out without seeing the splicing 
transaction getting invalidated, it will publish the latest old commitment 
transaction and the latest new commitment transaction and consider the channel 
as closing and tracking it as a unilateral close, checking for either the old 
funding output or the new funding output to be spent.