[Lightning-dev] Including a Protocol for splicing to BOLT

[ZmnSCPxj]

Good morning Laolu,

>> but even though it seems technically straight forward t
>
> Well the full async implementation may be a bit involved, depending on the
> architecture of the implementation (see the second point below).
>
> In the abstract, I'd say a splicing proposal should include the following:
>
>   * a generic message for both splice in/out
>     * this allows both sides to schedule/queue up possible changes,
>       opportunistically piggy-backing then on top of the other sides
>       initiation
>     * most of the channel params can also be re-negotiated as this point,
>       another upside is this effectively allows garbage collecting old
>       revocation state
>   * fully async splice in/out
>      * async is ideal as we don't need to block channel operation for
>        confirmations, this greatly improves the UX of the process
>      * async splice in should use a technique similar to what Conner has
>        suggested in the past [0], otherwise it would need to block :(

It increases complexity. I suppose it would be OK to limit splice-in so that if a splice-in has not been buried deeply in the chain yet, you cannot splice-in even more, to limit the number of parallel updates you need to keep track of to only 2.

>   * a sort of pre-announcement gossip messages
>      * purpose of this is to signal to other nodes "hey this channel is
>        about to change outpoints, but you can keep routing through it"
>      * otherwise, if this doesn't exist, then nodes would interpret the
>        action as a close then open of a channel, rather than a re-allocation

At first it seems benign to me -- after all, the channel is simply "reopened" and what does it matter whether other nodes know if the new channel is the same as the old channel? -- but then there will be a time of a few blocks where other nodes consider the channel closed but the replacement channel is not yet deep enough onchain to be reannounced.  So I suppose it enables routing across the channel during those few blocks.

Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180626/2a4b4ee6/attachment.html>