📅 Original date posted:2022-06-30
📝 Original message:
Had another thought: if you've seen a chain close but also have a gossip
message that
indicates this is a splice, you SHOULD propagate that gossip more
urgently/widely than
any other gossip you've got. Adding an urgency metric to gossip is fuzzy to
enforce... *handwaves*.
You *do* get the onchain signal, we just change the behavior of the
secondary information system
instead of embedding the info into the chain..
"Spamming" gossip with splices expensive -- there's a real-world cost
(onchain fees) to
closing a channel (the signal to promote/prioritize a gossip msg) which
cuts down on the ability to send out these 'urgent' messages with any
frequency.
~nifty
On Wed, Jun 29, 2022 at 7:43 PM lisa neigut <niftynei at gmail.com> 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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220629/b97093da/attachment.html>;
lisa neigut [ARCHIVE] /
npub1sp…s64t2
2023-06-09 13:06:23
in reply to nevent1q…6fea
Author Public Key
npub1sprhp66c693av0c0n9had046hcdcckp2th25fnmphwstc5e4wg9qxs64t2Published at
2023-06-09 13:06:23Event JSON
{
"id": "bd4782d4746cb3a2e0543853c2ac901833798739ee22e93705e2f3c54a5f9543",
"pubkey": "804770eb58d163d63f0f996fd6bebabe1b8c582a5dd544cf61bba0bc5335720a",
"created_at": 1686315983,
"kind": 1,
"tags": [
[
"e",
"68aec1f99cd4e5b941681a4766e53315d87dc392151785eee1eb3e4b5e7f9a3f",
"",
"root"
],
[
"e",
"f4c0ee4281dac621720362c66b22f7e9d71871351e886cc4ca07fefa22abf31d",
"",
"reply"
],
[
"p",
"804770eb58d163d63f0f996fd6bebabe1b8c582a5dd544cf61bba0bc5335720a"
]
],
"content": "📅 Original date posted:2022-06-30\n📝 Original message:\nHad another thought: if you've seen a chain close but also have a gossip\nmessage that\nindicates this is a splice, you SHOULD propagate that gossip more\nurgently/widely than\nany other gossip you've got. Adding an urgency metric to gossip is fuzzy to\nenforce... *handwaves*.\n\nYou *do* get the onchain signal, we just change the behavior of the\nsecondary information system\ninstead of embedding the info into the chain..\n\n\"Spamming\" gossip with splices expensive -- there's a real-world cost\n(onchain fees) to\nclosing a channel (the signal to promote/prioritize a gossip msg) which\ncuts down on the ability to send out these 'urgent' messages with any\nfrequency.\n\n~nifty\n\nOn Wed, Jun 29, 2022 at 7:43 PM lisa neigut \u003cniftynei at gmail.com\u003e wrote:\n\n\u003e Adding a noticeable on-chain signal runs counter to the goal of the move\n\u003e to taproot / gossip v2, which is to make lightning's onchain footprint\n\u003e indistinguishable from\n\u003e any other onchain usage.\n\u003e\n\u003e I'm admittedly a bit confused as to why onchain signals are even being\n\u003e seriously\n\u003e proposed. Aside from \"infallibility\", is there another reason for\n\u003e suggesting\n\u003e we add an onchain detectable signal for this? Seems heavy handed imo,\n\u003e given\n\u003e that the severity of a comms failure is pretty minimal (*potential* for\n\u003e lost routing fees).\n\u003e\n\u003e \u003e So it appears you don't agree that the \"wait N blocks before you close\n\u003e your\n\u003e channels\" isn't a fool proof solution? Why 12 blocks, why not 15? Or 144?\n\u003e\n\u003e fwiw I seem to remember seeing that it takes ~an hour for gossip to\n\u003e propagate\n\u003e (no link sorry). Given that, 2x an hour or 12 blocks is a reasonable first\n\u003e estimate.\n\u003e I trust we'll have time to tune this after we've had some real-world\n\u003e experience with them.\n\u003e\n\u003e Further, we can always add more robust signaling later, if lost routing\n\u003e fees turns\n\u003e out to be a huge issue.\n\u003e\n\u003e Finally, worth noting that Alex Myer's minisketch project may well\n\u003e help/improve gossip\n\u003e reconciliation efficiency to the point where gossip reliability is less\n\u003e of an issue.\n\u003e\n\u003e ~nifty\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220629/b97093da/attachment.html\u003e",
"sig": "9339eac21c778b5c4628c93a1a0126d7d785d53ec7ce79bb2c86f0bbd3f3435671d957d27dff60edad9ef3b4c426a2dc19147f05992c139d369d4d00d6be74c8"
}