ZmnSCPxj via Lightning-dev <firstname.lastname@example.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 into one. > 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 > 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. 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. _______________________________________________ Lightning-dev mailing list Lightningemail@example.com https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev