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
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
