bolts
bolts copied to clipboard
lightning
gossip: delay considering a channel edge deleted for 12-blocks
Allows us time to propagate a splice update (new channel_announcement)
Suggested-By: @t-bast Co-Authored: @ddustin
I'd like to spend more time exploring the design space for splicing before acking this, sorry if it takes some time before I can comment!
What's the worry with Just Doing This? It seems good to get moving on this a ways before it's needed.
What's the worry with Just Doing This? It seems good to get moving on this a ways before it's needed.
IMO in practice the signal will be pretty unreliable due to strictly relying on timely gossip message propagation. There also isn't a good way to track the actual observance of this, since it's more or less just a guideline.
I wrote more about this here, along with a suggestion for a primary chain signal, with the gossip signal (w/e that looks like) being secondary: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-June/003616.html
That's what I had in mind, my thinking was that the splicing tx would be somehow identifiable as a splicing tx so that we don't need this 12-blocks delay at all. But the issue is that we'd like implementations to deploy code to identify this signal before we actually deploy splicing...
We can also choose to do both: delay considering a channel edge deleted for 12 blocks, which implementations can do today and will help splicing when it happens, even though it's not a perfect solution, and then implement a signal in the splicing tx to improve reliability, that would work for me - but it's only useful if all implementations agree to ship this 12 blocks delay in the short term.
Here's a thought (also posted to ML): if you're in possession of a channel_announcement which indicates that it's a splice and you've seen a channel btw the same two peers close, you SHOULD prioritize spreading that gossip message to every peer you're connected to/have a channel with.
This is nice because it uses the on-chain signaling that @Roasbeef proposed, but doesn't require new protocol design, just changing the priority/scope of which you gossip a subset of messages.
This is nicely spam compatible. Splice gossip has a natural rate-limit/real world cost in that triggering the close onchain costs sats; you can't generate a lot of urgent gossip messages w/o sending money to the L1 miners.
I honestly don't really understand this discussion. Gossip is never reliable, it was never meant to be reliable, and its always been best-effort. All nodes cooperate to try to make sure they all have as much a view of the routing table as possible, to ensure they have all the information they can when routing. If you're splicing, you're always going to have some users running today's software that will not be happy seeing the splice on-chain, this is true no matter what we do. If the concern is that 12 blocks isn't enough, well, then we can simply increase the constant, easy-peasy. Making sure splices are identifiable on-chain is wasteful and doesn't solve the issue as stated here except for new nodes, just like waiting to remove channels. Please, lets not over-complicate things...
Agreed with @TheBlueMatt: the gossip is intended as a best effort system, and striving for completeness or timeliness is likely a far deeper Rabbit Hole than we're willing to tackle (now or potentially ever).
As for the actual number, 12 blocks seems like plenty: 6 blocks to make the New version announceable, plus 6 blocks for propagation (see #1001 for a back of the envelope calculation).
Do we also want onchain signaling? I'm not sure we want to make transactions identifiable beyond what we already have, but it might not be a huge loss here (we're gossiping about these outpoints anyway) and a belts and suspenders variant might be sensible.
This is all going to change when we detach gossip from onchain outpoints anyway, so maybe better not to overthink it here?
Shall we merge this now? The previous spec meeting had acks from eclair, cln and ldk and @Roasbeef wasn't opposed to it?