đź“… Original date posted:2022-04-15
đź“ť Original message:
Good morning Alex,
I’ve been investigating set reconciliation as a means to reduce bandwidth
and redundancy of gossip message propagation.
>
Cool project, glad to see someone working on it! The main difficulty here
will
indeed be to ensure that the number of differences between sets is bounded.
We will need to maintain a mechanism to sync the whole graph from scratch
for new nodes, so the minisketch diff must be efficient enough otherwise
nodes
will just fall back to a full sync way too often (which would waste a lot of
bandwidth).
Picking several offending channel ids, and digging further, the majority of
> these
appear to be flapping due to Tor or otherwise intermittent connections.
>
One thing that may help here from an implementation's point of view is to
avoid
sending a disabled channel update every time a channel goes offline. What
eclair does to avoid spamming is to only send a disabled channel update when
someone actually tries to use that channel. Of course, if people choose this
offline node in their route, you don't have a choice and will need to send a
disabled channel update, but we've observed that many channels come back
online before we actually need to use them, so we're saving two channel
updates
(one to disable the channel and one to re-enable it). I think all
implementations
should do this. Is that the case today?
We could go even further, and when we receive an htlc that should be relayed
to an offline node, wait a bit to give them an opportunity to come online
instead
of failing the htlc and sending a disabled channel update. Eclair currently
doesn't
do that, but it would be very easy to add.
- A common listing of current default rate limits across lightning network
> implementations.
>
Eclair doesn't do any rate-limiting. We wanted to "feel the pain" before
adding
anything, and to be honest we haven't really felt it yet.
which will use a common, simple heuristic to accept or reject a gossip
> message.
(Think one channel update per block, or perhaps one per block_height << 5.)
>
I think it would be easy to come to agreement between implementations and
restrict channel updates to at most one every N blocks. We simply need to
add
the `block_height` in a tlv in `channel_update` and then we'll be able to
actually
rate-limit based on it. Given how much time it takes to upgrade most of the
network, it may be a good idea to add the `block_height` tlv now in the
spec,
and act on it later? Unless your work requires bigger changes in channel
update
in which case it will probably be a new message.
Note that it will never be completely accurate though, as different nodes
can
have different blockchain tips. My nodes may be one or two blocks late
compared
to the node that emits the channel update. We need to allow a bit of leeway
there.
Cheers,
Bastien
Le jeu. 14 avr. 2022 Ă 23:06, Alex Myers <alex at endothermic.dev> a Ă©crit :
> Hello lightning developers,
>
>
> I’ve been investigating set reconciliation as a means to reduce bandwidth
> and redundancy of gossip message propagation. This builds on some earlier work
> from Rusty using the minisketch library [1]. The idea is that each node
> will build a sketch representing it’s own gossip set. Alice’s node will
> encode and transmit this sketch to Bob’s node, where it will be merged with
> his own sketch, and the differences produced. These differences should
> ideally be exactly the latest missing gossip of both nodes. Due to size
> constraints, the set differences will necessarily be encoded, but Bob’s
> node will be able to identify which gossip Alice is missing, and may then
> transmit exactly those messages.
>
>
> This process is relatively straightforward, with the caveat that the sets
> must otherwise match very closely (each sketch has a maximum capacity for
> differences.) The difficulty here is that each node and lightning
> implementation may have its own rules for gossip acceptance and
> propagation. Depending on their gossip partners, not all gossip may
> propagate to the entire network.
>
>
> Core-lightning implements rate limiting for incoming channel updates and
> node announcements. The default rate limit is 1 per day, with a burst of
> 4. I analyzed my node’s gossip over a 14 day period, and found that, of
> all publicly broadcasting half-channels, 18% of them fell afoul of our
> spam-limiting rules at least once. [2]
>
>
> Picking several offending channel ids, and digging further, the majority
> of these appear to be flapping due to Tor or otherwise intermittent
> connections. Well connected nodes may be more susceptible to this due to more
> frequent routing attempts, and failures resulting in a returned channel
> update (which otherwise might not have been broadcast.) A slight
> relaxation of the rate limit resolves the majority of these cases.
>
>
> A smaller subset of channels broadcast frequent channel updates with minor
> adjustments to htlc_maximum_msat and fee_proportional_millionths
> parameters. These nodes appear to be power users, with many channels and
> large balances. I assume this is automated channel management at work.
>
>
> Core-Lightning has updated rate-limiting in the upcoming release to
> achieve a higher acceptance of incoming gossip, however, it seems that a
> broader discussion of rate limits may now be worthwhile. A few immediate
> ideas:
>
> - A common listing of current default rate limits across lightning
> network implementations.
>
> - Internal checks of RPC input to limit or warn of network propagation
> issues if certain rates are exceeded.
>
> - A commonly adopted rate-limit standard.
>
>
> My aim is a set reconciliation gossip type, which will use a common,
> simple heuristic to accept or reject a gossip message. (Think one channel
> update per block, or perhaps one per block_height << 5.) See my github
> for my current draft. [3] This solution allows tighter consensus, yet suffers
> from the same problem as original anti-spam measures – it remains
> somewhat arbitrary. I would like to start a conversation regarding gossip
> propagation, channel_update and node_announcement usage, and perhaps even
> bandwidth goals for syncing gossip in the future (how about a million
> channels?) This would aid in the development of gossip set
> reconciliation, but could also benefit current node connection and
> routing reliability more generally.
>
>
> Thanks,
>
> Alex
>
>
> [1] https://github.com/sipa/minisketch
>
> [2]
> https://github.com/endothermicdev/lnspammityspam/blob/main/sampleoutput.txt
>
> [3]
> https://github.com/endothermicdev/lightning-rfc/blob/gossip-minisketch/07-routing-gossip.md#set-reconciliation
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220415/98a7eca4/attachment-0001.html>;
Bastien TEINTURIER [ARCHIVE] /
npub17f…ntr0s
2023-06-09 13:05:51
in reply to nevent1q…p56a
Author Public Key
npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0sPublished at
2023-06-09 13:05:51Event JSON
{
"id": "5ca790165c4d8a69ac230bceb2611d51e6ca66609c442b32874e5732385556ba",
"pubkey": "f26569a10f83f6935797b8b53a87974fdcc1de6abd31e3b1a3a19bdaed8031cb",
"created_at": 1686315951,
"kind": 1,
"tags": [
[
"e",
"90c8a22893d09190339208f6b0eb636d6de40a2b6c7cff5708a261796a93b71e",
"",
"root"
],
[
"e",
"4d4c58af7e2482f492c5694b61e6963d5814d0a3bd65bd193434713d45ad94ff",
"",
"reply"
],
[
"p",
"52b603cc7527b671d1636a488828123ae7e57dadefec3b4182df7f134485426e"
]
],
"content": "📅 Original date posted:2022-04-15\n📝 Original message:\nGood morning Alex,\n\nI’ve been investigating set reconciliation as a means to reduce bandwidth\n\nand redundancy of gossip message propagation.\n\u003e\n\nCool project, glad to see someone working on it! The main difficulty here\nwill\nindeed be to ensure that the number of differences between sets is bounded.\nWe will need to maintain a mechanism to sync the whole graph from scratch\nfor new nodes, so the minisketch diff must be efficient enough otherwise\nnodes\nwill just fall back to a full sync way too often (which would waste a lot of\nbandwidth).\n\nPicking several offending channel ids, and digging further, the majority of\n\u003e these\n\nappear to be flapping due to Tor or otherwise intermittent connections.\n\u003e\n\nOne thing that may help here from an implementation's point of view is to\navoid\nsending a disabled channel update every time a channel goes offline. What\neclair does to avoid spamming is to only send a disabled channel update when\nsomeone actually tries to use that channel. Of course, if people choose this\noffline node in their route, you don't have a choice and will need to send a\ndisabled channel update, but we've observed that many channels come back\nonline before we actually need to use them, so we're saving two channel\nupdates\n(one to disable the channel and one to re-enable it). I think all\nimplementations\nshould do this. Is that the case today?\n\nWe could go even further, and when we receive an htlc that should be relayed\nto an offline node, wait a bit to give them an opportunity to come online\ninstead\nof failing the htlc and sending a disabled channel update. Eclair currently\ndoesn't\ndo that, but it would be very easy to add.\n\n- A common listing of current default rate limits across lightning network\n\u003e implementations.\n\u003e\n\nEclair doesn't do any rate-limiting. We wanted to \"feel the pain\" before\nadding\nanything, and to be honest we haven't really felt it yet.\n\nwhich will use a common, simple heuristic to accept or reject a gossip\n\u003e message.\n\n(Think one channel update per block, or perhaps one per block_height \u003c\u003c 5.)\n\u003e\n\nI think it would be easy to come to agreement between implementations and\nrestrict channel updates to at most one every N blocks. We simply need to\nadd\nthe `block_height` in a tlv in `channel_update` and then we'll be able to\nactually\nrate-limit based on it. Given how much time it takes to upgrade most of the\nnetwork, it may be a good idea to add the `block_height` tlv now in the\nspec,\nand act on it later? Unless your work requires bigger changes in channel\nupdate\nin which case it will probably be a new message.\n\nNote that it will never be completely accurate though, as different nodes\ncan\nhave different blockchain tips. My nodes may be one or two blocks late\ncompared\nto the node that emits the channel update. We need to allow a bit of leeway\nthere.\n\nCheers,\nBastien\n\n\n\n\nLe jeu. 14 avr. 2022 à 23:06, Alex Myers \u003calex at endothermic.dev\u003e a écrit :\n\n\u003e Hello lightning developers,\n\u003e\n\u003e\n\u003e I’ve been investigating set reconciliation as a means to reduce bandwidth\n\u003e and redundancy of gossip message propagation. This builds on some earlier work\n\u003e from Rusty using the minisketch library [1]. The idea is that each node\n\u003e will build a sketch representing it’s own gossip set. Alice’s node will\n\u003e encode and transmit this sketch to Bob’s node, where it will be merged with\n\u003e his own sketch, and the differences produced. These differences should\n\u003e ideally be exactly the latest missing gossip of both nodes. Due to size\n\u003e constraints, the set differences will necessarily be encoded, but Bob’s\n\u003e node will be able to identify which gossip Alice is missing, and may then\n\u003e transmit exactly those messages.\n\u003e\n\u003e\n\u003e This process is relatively straightforward, with the caveat that the sets\n\u003e must otherwise match very closely (each sketch has a maximum capacity for\n\u003e differences.) The difficulty here is that each node and lightning\n\u003e implementation may have its own rules for gossip acceptance and\n\u003e propagation. Depending on their gossip partners, not all gossip may\n\u003e propagate to the entire network.\n\u003e\n\u003e\n\u003e Core-lightning implements rate limiting for incoming channel updates and\n\u003e node announcements. The default rate limit is 1 per day, with a burst of\n\u003e 4. I analyzed my node’s gossip over a 14 day period, and found that, of\n\u003e all publicly broadcasting half-channels, 18% of them fell afoul of our\n\u003e spam-limiting rules at least once. [2]\n\u003e\n\u003e\n\u003e Picking several offending channel ids, and digging further, the majority\n\u003e of these appear to be flapping due to Tor or otherwise intermittent\n\u003e connections. Well connected nodes may be more susceptible to this due to more\n\u003e frequent routing attempts, and failures resulting in a returned channel\n\u003e update (which otherwise might not have been broadcast.) A slight\n\u003e relaxation of the rate limit resolves the majority of these cases.\n\u003e\n\u003e\n\u003e A smaller subset of channels broadcast frequent channel updates with minor\n\u003e adjustments to htlc_maximum_msat and fee_proportional_millionths\n\u003e parameters. These nodes appear to be power users, with many channels and\n\u003e large balances. I assume this is automated channel management at work.\n\u003e\n\u003e\n\u003e Core-Lightning has updated rate-limiting in the upcoming release to\n\u003e achieve a higher acceptance of incoming gossip, however, it seems that a\n\u003e broader discussion of rate limits may now be worthwhile. A few immediate\n\u003e ideas:\n\u003e\n\u003e - A common listing of current default rate limits across lightning\n\u003e network implementations.\n\u003e\n\u003e - Internal checks of RPC input to limit or warn of network propagation\n\u003e issues if certain rates are exceeded.\n\u003e\n\u003e - A commonly adopted rate-limit standard.\n\u003e\n\u003e\n\u003e My aim is a set reconciliation gossip type, which will use a common,\n\u003e simple heuristic to accept or reject a gossip message. (Think one channel\n\u003e update per block, or perhaps one per block_height \u003c\u003c 5.) See my github\n\u003e for my current draft. [3] This solution allows tighter consensus, yet suffers\n\u003e from the same problem as original anti-spam measures – it remains\n\u003e somewhat arbitrary. I would like to start a conversation regarding gossip\n\u003e propagation, channel_update and node_announcement usage, and perhaps even\n\u003e bandwidth goals for syncing gossip in the future (how about a million\n\u003e channels?) This would aid in the development of gossip set\n\u003e reconciliation, but could also benefit current node connection and\n\u003e routing reliability more generally.\n\u003e\n\u003e\n\u003e Thanks,\n\u003e\n\u003e Alex\n\u003e\n\u003e\n\u003e [1] https://github.com/sipa/minisketch\n\u003e\n\u003e [2]\n\u003e https://github.com/endothermicdev/lnspammityspam/blob/main/sampleoutput.txt\n\u003e\n\u003e [3]\n\u003e https://github.com/endothermicdev/lightning-rfc/blob/gossip-minisketch/07-routing-gossip.md#set-reconciliation\n\u003e\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220415/98a7eca4/attachment-0001.html\u003e",
"sig": "9a64deff71ae180fcc5232c95d88224b80d4e3c21a3a417e61d1476ffba971db25c6636a0ee74082da6de99c18f8709231a24ad1a4480f7cdf929cc0f9d9e593"
}