[Lightning-dev] Closing Transaction Cut-through as a Generalization of Splice-in/Splice-out
decker.christian at gmail.com
Wed Apr 11 17:38:47 UTC 2018
ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org> writes:
> 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.
We could go a bit further and have both sides provide incomplete and
unsigned stubs, that would then be applied to the closing transaction:
inputs in the stubs are added as inputs to the closing transaction
adding to the balance of the providing party, and outputs are also added
to the closing transaction, drawing from the balance of the party adding
the new output. This way we can perform any number of splice-in / -out
operations in a single reseat operation. Not sure if we need to have any
additional negotiation besides this. Admittedly using tx formatted
messages to transport the intent is not really necessary, but it
reconnects to the idea of cut-through, combining multiple 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.
That may complicate the state tracking a bit, but we'll eventually have
transactions that assume multiple roles anyway, so that sounds ok.
> 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
> 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.
The connection the channel factories is not really necessary, as long as
we have an invalidation scheme that allows us to invalidate a prior
funding transaction we can reseat without needing a cut-through, just
invalidate the funding tx of the old channel and add the funding tx for
the new one in the new state.
More information about the Lightning-dev