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

[Rusty Russell]

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  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

[Lightning-dev] Rebalancing argument

[Dmytro Piatkivskyi]

Hi everyone,

I have been working academically on the Lightning network for a while now. I 
didn't not participate in the list to form my own vision of what it should be. 
So please, bear with me if I'll be saying nonsense sometimes.

There has been a lot of discussion on sending cycle transactions to oneself to 
're-balance' the network. On LN mailing 
list
 [1] or numerous places elsewhere. There has been even a paper suggesting a 
smart mechanism to do the re-balancing (see Revive or Liquidity network [2]). 
My question is what do we actually get from it? [3] states that the 
distribution of funds in channels does not really affect the network liquidity. 
I can see cheaper fees or shorter paths if the network is kept balanced. But 
don't you think that a smart fee strategy will do the job?

To save your time, [4] explains the gist from [3].

[1] 
https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/001005.html
[2] 
https://www.reddit.com/r/ethereum/comments/7bse33/were_very_happy_to_announce_the_liquiditynetwork/
[3] https://arxiv.org/abs/1007.0515
[4] 
https://medium.com/@dimapiatkivskyi/why-would-you-re-balance-a-payment-network-796756ad4f31
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev