ZmnSCPxj via Lightning-dev <lightning-dev@lists.linuxfoundation.org> writes: > For myself, I think, for old nodes, it should just appear as a > "normal" close followed by a "normal" open.
That's exactly what they should look like, since the channel is being closed with the existing protocol and opened (possibly with a slightly different value). > 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. I thought of it more as a new alias for the old channel, so that the update in the network view is just switching names after the announce depth is reached. > 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. The message announcing the reopen or the alias should probably preceed the actual close, otherwise nodes may prune the channel from their view upon seeing the close. The message then simply has the effect of saying "ignore the close, let it linger for 6 more blocks before really removing from your network view". > 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). Agreed, multipath routing is a priority, but I think splicing is just as much a key piece to a better UX, since it allows to ignore differences between on-chain and off-chain funds, showing just a single balance for all use-cases. > With AMP, size of channels is less important, and many small channels > will work almost as well as a few large channels. Well, capacities are still very much important, and if there is a smaller min-cut separating source and destination than the total amount of the payment, then the payment will still fail. We now simply no longer require a single channel with sufficient capacity to exist. _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
