rich1.0Rusty Russell [ARCHIVE] (npub1zw…hkhpx)https://yabu.me/npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxnjumphttps://yabu.me📅 Original date posted:2022-06-28 📝 Original message: Hi Roasbeef, This is over-design: if you fail to get reliable gossip, your routing will suffer anyway. Nothing new here. And if you *know* you're missing gossip, you can simply delay onchain closures for longer: since nodes should respect the old channel ids for a while anyway. Matt's proposal to simply defer treating onchain closes is elegant and minimal. We could go further and relax requirements to detect onchain closes at all, and optionally add a perm close message. Cheers, Rusty. Olaoluwa Osuntokun <laolu32 at gmail.com> writes: > Hi y'all, > > This mail was inspired by this [1] spec PR from Lisa. At a high level, it > proposes the nodes add a delay between the time they see a channel closed on > chain, to when they remove it from their local channel graph. The motive > here is to give the gossip message that indicates a splice is in process, > "enough" time to propagate through the network. If a node can see this > message before/during the splicing operation, then they'll be able relate > the old and the new channels, meaning it's usable again by senders/receiver > _before_ the entire chain of transactions confirms on chain. > > IMO, this sort of arbitrary delay (expressed in blocks) won't actually > address the issue in practice. The proposal suffers from the following > issues: > > 1. 12 blocks is chosen arbitrarily. If for w/e reason an announcement > takes longer than 2 hours to reach the "economic majority" of > senders/receivers, then the channel won't be able to mask the splicing > downtime. > > 2. Gossip propagation delay and offline peers. These days most nodes > throttle gossip pretty aggressively. As a result, a pair of nodes doing > several in-flight splices (inputs become double spent or something, so > they need to try a bunch) might end up being rate limited within the > network, causing the splice update msg to be lost or delayed significantly > (IIRC CLN resets these values after 24 hours). On top of that, if a peer > is offline for too long (think mobile senders), then they may miss the > update all together as most nodes don't do a full historical > _channel_update_ dump anymore. > > In order to resolve these issues, I think instead we need to rely on the > primary splicing signal being sourced from the chain itself. In other words, > if I see a channel close, and a closing transaction "looks" a certain way, > then I know it's a splice. This would be used in concert w/ any new gossip > messages, as the chain signal is a 100% foolproof way of letting an aware > peer know that a splice is actually happening (not a normal close). A chain > signal doesn't suffer from any of the gossip/time related issues above, as > the signal is revealed at the same time a peer learns of a channel > close/splice. > > Assuming, we agree that a chain signal has some sort of role in the ultimate > plans for splicing, we'd need to decide on exactly _what_ such a signal > looks like. Off the top, a few options are: > > 1. Stuff something in the annex. Works in theory, but not in practice, as > bitcoind (being the dominant full node implementation on the p2p network, > as well as what all the miners use) treats annexes as non-standard. Also > the annex itself might have some fundamental issues that get in the way of > its use all together [2]. > > 2. Re-use the anchors for this purpose. Anchor are nice as they allow for > 1st/2nd/3rd party CPFP. As a splice might have several inputs and outputs, > both sides will want to make sure it gets confirmed in a timely manner. > Ofc, RBF can be used here, but that requires both sides to be online to > make adjustments. Pre-signing can work too, but the effectiveness > (minimizing chain cost while expediting confirmation) would be dependent > on the fee step size. > > In this case, we'd use a different multi-sig output (both sides can rotate > keys if they want to), and then roll the anchors into this splicing > transaction. Given that all nodes on the network know what the anchor size > is (assuming feature bit understanding), they're able to realize that it's > actually a splice, and they don't need to remove it from the channel graph > (yet). > > 3. Related to the above: just re-use the same multi-sig output. If nodes > don't care all that much about rotating these keys, then they can just use > the same output. This is trivially recognizable by nodes, as they already > know the funding keys used, as they're in the channel_announcement. > > 4. OP_RETURN (yeh, I had to list it). Self explanatory, push some bytes in > an OP_RETURN and use that as the marker. > > 5. Fiddle w/ the locktime+sequence somehow to make it identifiable to > verifiers. This might run into some unintended interactions if the inputs > provided have either relative or absolute lock times. There might also be > some interaction w/ the main constructing for eltoo (uses the locktime). > > Of all the options, I think #2 makes the most sense: we already use anchors > to be able to do fee bumping after-the-fact for closing transactions, so why > not inherit them here. They make the splicing transaction slightly larger, > so maybe #3 (or something else) is a better choice. > > The design space for spicing is preeetty large, so I figure the most > productive route might be discussing isolated aspects of it at a time. > Personally, I'm not suuuper caught up w/ what the latest design drafts are > (aside from convos at the recent LN Dev Summit), but from my PoV, how to > communicate the splice to other peers has been an outstanding design > question. > > [1]: https://github.com/lightning/bolts/pull/1004 > [2]: > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020045.html > > -- Laolu > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev