Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2018-07-01 📝 Original message: I'm delighted someone is ...
📅 Original date posted:2018-07-01
📝 Original message:
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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
📝 Original message:
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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev