Good morning all, > The gossip extension is difficult: > > 3. 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. > > 4. If we extend channel_update it won't propagate once the new spend is seen > > on the bitcoin network. > > 5. 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.
For myself, I think, for old nodes, it should just appear as a "normal" close followed by a "normal" open. So, instead, maybe a new `channel_announce_reopen` which informs everyone that an old scid will eventually become a new scid, and that the nodes involved will still consider routes via the old scid to be valid regardless. Then an ordinary `channel_announce` once the announce depth of the new scid is reached. >From point of view of old nodes, the channel is closed for some blocks, but a >new channel between the two nodes is then announced. >From point of view of new nodes, the channel is referred to using the previous >scid, until an ordinary `channel_announce` is received, and then the channel >is referred to using the new scid. --- For myself, I think splice is less priority than AMP. But I prefer an AMP which retains proper ZKCP (i.e. receipt of preimage at payer implies receipt of payment at payee, to facilitate trustless on-to-offchain and off-to-onchain bridges). With AMP, size of channels is less important, and many small channels will work almost as well as a few large channels. On-to-offchain and off-to-onchain bridges form a different layer and moves complexity from Lightning protocol to a different "bridge" layer. These bridges also make dual-funding channels less necessary (the main reason for dual-funding is to get incoming capacity, and incoming capacity can be easily had with some spare BTC and an off-to-onchain bridge (use onchain funds to make channel to anywhere, pay off-to-onchain bridge to give you back onchain funds, et voila you have incoming channel), and providing the bridge service is properly incentivized, too, so we do not need to worry about proper incentives for dual-funding). Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
