[Lightning-dev] Closing Transaction Cut-through as a Generalization of Splice-in/Splice-out

ZmnSCPxj ZmnSCPxj at protonmail.com
Tue Apr 10 09:44:15 UTC 2018

Good morning list,

I have the below speculation idea.

Suppose, rather than implement a splice-in/splice-out ("channel top-up", etc.) we instead implement a more general "cut-through" for a channel close transaction.

Normally a channel close spends a single input and makes 1 or 2 outputs.  Instead of such a simple transaction, both sides could additionally provide signed normal transactions that spend the outputs, then they could cooperatively create a new close transaction that cuts through the original close transaction and the additional normal transactions.

A splice-in and splice-out would then be a closing transaction that gets cut-through with a funding transaction to the same peer.

The generalization is useful if we want to "reseat" a channel to one peer to another peer.  For example, if the node keeps payment statistics and notices that the channel with one peer always has a high probability of failing to forward to a destination, then it could decide to close that channel and open a channel to some other peer.  This reseat operation could use the closing transaction cut-through to close the channel and open to another peer in a single onchain transaction.

Such a reseat operation also seems like a reasonable primitive for Burchert-Decker-Wattenhofer channel factories to offer; reseats can be done offchain if both the reseat-form peer and the reseat-to peer and the node belong to the same channel factory.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180410/da93ba65/attachment.html>

More information about the Lightning-dev mailing list