Re: [Lightning-dev] Closing Transaction Cut-through as a Generalization of Splice-in/Splice-out
Good morning Christian, > > 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. Indeed, it is unnecessary at all. My consideration, was that we could present it as an operation to wallet implementers (or advanced users). In much the same way that it would be sensible to present a `multifundchannel` command at c-lightning RPC level, it would be sensible to present a `reseatchannel` command at c-lightning RPC level to transfer the remaining funds of a channel from one peer to a new channel to another (or possibly to splice-out from one and immediately splice-in to another). Prior to Burchert-Decker-Wattenhofer channel factories being deployed, `multifundchannel` and `reseatchannel` would use current operations (multiple channel funding txouts from one funding tx for the former, separate close-then-open operations for the latter (possibly implemented with cut-through if it can be specced)). Then when the Burchert-Decker-Wattenhofer channel factories are deployed we can optimize (`multifundchannel` actually creates a new channel factory with this node and all nodes listed in the multi-fund operation as members of the factory, with the starting fund only happening to come from this node only; `reseatchannel` is an offchain channel reorganization request to the factory). Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Closing Transaction Cut-through as a Generalization of Splice-in/Splice-out
ZmnSCPxj via Lightning-dev 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
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Closing Transaction Cut-through as a Generalization of Splice-in/Splice-out
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.
Regards,
ZmnSCPxj___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
