From laolu32 at gmail.com Sat Jul 2 00:26:54 2022 From: laolu32 at gmail.com (Olaoluwa Osuntokun) Date: Fri, 1 Jul 2022 17:26:54 -0700 Subject: [Lightning-dev] Achieving Zero Downtime Splicing in Practice via Chain Signals In-Reply-To: References: <87a69wb62i.fsf@rustcorp.com.au> Message-ID: Hi Lisa, > Adding a noticeable on-chain signal runs counter to the goal of the move > to taproot / gossip v2, which is to make lightning's onchain footprint > indistinguishable from any other onchain usage My model of gossip v2 is something like: * there's no longer a 1:1 mapping of channels and UTXOs * verifiers don't actually care if the advertised UTXO is actually a channel or not * verifiers aren't watching the chain for spends, as channel advertisements expire after 2 weeks or w/e * there might be a degree of "leverage" allowing someone to advertise a 1 BTC UTXO as having 10 BTC capacity (or w/e) So in this model, splicing on the gossip network wouldn't really be an explicit event. Since I'm free to advertise a series of channels that might not actually exist, I can just say: ok, this set of 5 channels is now actually 2 channels, and you can route a bit more over them. In this world, re-organizing by a little corner of the channel graph isn't necessarily tied to making a series of on-chain transactions. In the realm of the gossip network as it's defined today, the act of splicing is already itself a noticeable chain signal: I see a channel close, then another one advertised that uses that old channel as inputs, and the closing and opening transactions are the same. As a result, for _public_ channels any of the chain signals I listed above don't actually give away any additional information: splices are already identifiable (in theory). I don't disagree that waiting N blocks is probably "good enough" for most cases (ignoring block storms, rare long intervals between blocks, etc, etc). Instead this is suggested in the spirit of a belt-and-suspenders approach: if I can do something to make the signal 100% reliable, that doesn't add extra bytes to the chain, and doesn't like additional information for public channels (the only case where the message even matters), then why not? -- Laolu On Wed, Jun 29, 2022 at 5:43 PM lisa neigut wrote: > Adding a noticeable on-chain signal runs counter to the goal of the move > to taproot / gossip v2, which is to make lightning's onchain footprint > indistinguishable from > any other onchain usage. > > I'm admittedly a bit confused as to why onchain signals are even being > seriously > proposed. Aside from "infallibility", is there another reason for > suggesting > we add an onchain detectable signal for this? Seems heavy handed imo, > given > that the severity of a comms failure is pretty minimal (*potential* for > lost routing fees). > > > So it appears you don't agree that the "wait N blocks before you close > your > channels" isn't a fool proof solution? Why 12 blocks, why not 15? Or 144? > > fwiw I seem to remember seeing that it takes ~an hour for gossip to > propagate > (no link sorry). Given that, 2x an hour or 12 blocks is a reasonable first > estimate. > I trust we'll have time to tune this after we've had some real-world > experience with them. > > Further, we can always add more robust signaling later, if lost routing > fees turns > out to be a huge issue. > > Finally, worth noting that Alex Myer's minisketch project may well > help/improve gossip > reconciliation efficiency to the point where gossip reliability is less > of an issue. > > ~nifty > > -------------- next part -------------- An HTML attachment was scrubbed... URL: