I'm delighted someone is fleshing this out!

Splice-out is easy, splice-in is harder.

Note that there are two ways:

1. Broadcast a spend which joins with one or more random outputs and
   then maintain both the old and new channels (ie. both sets of
   signatures) until it confirms deeply enough.  This is the original
   plan, as detailed in [0].
2. Pre-commit. You either set up what is basically another funding tx,
   then join the channels together once it's deep enough.

The second is simpler, but requires two onchain txs, thus I prefer
the original model despite the complexity.

I think for 1.1 it's OK to limit this to one concurrent change at a
time (ie. for the 6 blocks or whatever, you can't organize *another*
splice in/out).

The gossip extension is difficult:

1. If we extend channel_announce that won't propagate through old nodes
   until the new channel is 6 deep, and it's wasted space (sigs + old-chanid)
   once the splice is old news.
2. If we extend channel_update it won't propagate once the new spend is seen
   on the bitcoin network.
3. A new message type won't propagate at all through old nodes: maybe it
   could be made so that the "splice information" sigs + old-chanid is
   discardable though.

Hmm...
Rusty.

ZmnSCPxj via Lightning-dev <lightning-dev@lists.linuxfoundation.org> writes:

> 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
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Reply via email to