lisa neigut [ARCHIVE] on Nostr: 📅 Original date posted:2022-06-29 📝 Original message: Adding a noticeable ...
📅 Original date posted:2022-06-29
📝 Original message:
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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220629/5a104870/attachment.html>
📝 Original message:
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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220629/5a104870/attachment.html>