Awesome, thanks Alex. Just one follow up.
> Running the numbers, I currently see 15,761 public nodes on the network and
> 148,295 half channels. Those each need refreshed gossip every two weeks. By
> default that would result in 90% channel updates.
And the rationale for each channel needing refreshed gossip every 2 weeks is to
inform the network that the channel is still active (i.e. not disabled) and its
parameters haven't changed?
(I did look it up in BOLT 7 [0] but it wasn't clear to me that a channel would
be assumed to be inactive/disabled if there wasn't a channel_update for 2
weeks.)
That seems a lot of gossip to me if the recommended behavior of routing nodes
is to maintain ~100 percent uptime and only when absolutely necessary change
the parameters of the channel. I guess the alternative of significantly less
gossip messages and a potential uptick in failed routes would be worse though.
[0]:
https://github.com/lightning/bolts/blob/master/07-routing-gossip.md#rationale-4
--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
Keybase: michaelfolkson
PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
------- Original Message -------
On Wednesday, June 29th, 2022 at 7:07 PM, Alex Myers <a...@endothermic.dev>
wrote:
> Hi Michael,
>
> Thanks for the transcript and the questions, especially those you asked in
> Gleb's original Erlay presentation.
>
> I tried to cover a lot of ground in only 30 minutes and the finer points may
> have suffered. The most significant difference in concern between bitcoin
> transaction relay and lightning gossip may be one of privacy: Source nodes of
> Bitcoin transactions have an interest in privacy (avoid trivially
> triangulating the source.) Lightning gossip is already signed by and linked
> to a node ID - the source is completely transparent by nature. The lack of a
> timing concern would allow for a global sketch where it would have been
> infeasible for Erlay (among other reasons such as DoS.)
>
>> Why are hash collisions a concern for Lightning gossip and not for Erlay? Is
>> it not a DoS vector for both?
>
> If lightning gossip were encoded for minisketch entries with the
> short_channel_id, it would create a unique fingerprint by default thanks to
> referencing the unique funding transaction on chain - no hashing required.
> This was Rusty's original concept and what I had been proceeding with.
> However, given the ongoing privacy discussion and desire to eventually
> decouple lightning channels from their layer one funding transaction (gossip
> v2), I think we should prepare for a future in which channels are not
> explicitly linked to a SCID. That means hashing just as in Erlay and the same
> DoS vector would be present. Salting with a per-peer shared secret works
> here, but the solution is driven back toward inventory sets.
>
>> It seems you are leaning towards per-peer sketches with inventory sets (like
>> Erlay) rather than global sketches.
>
>
> Yes. There are pros and cons to each method, but most critically, this would
> be compatible with eventual removal of the SCID.
>
>> Erlay falls back to flooding if the set reconciliation algorithm doesn't
>> work which I'm assuming you'll do with Lightning gossip.
>
> Fallback will take some consideration (Erlay's bisect is an elegant feature),
> but yes, flooding is still the ultimate fallback.
>
>> I was also surprised to hear that channel_update made up 97 percent of
>> gossip messages. Isn't it recommended that you don't make too changes to
>> your channel as it is likely to result in failed routed payments and being
>> dropped as a routing node for future payments? It seems that this advice
>> isn't being followed if there are so many channel_update messages being sent
>> around. I almost wonder if Lightning implementations should include user
>> prompts like "Are you sure you want to update your channel given this may
>> affect your routing success?" :)
>
> Running the numbers, I currently see 15,761 public nodes on the network and
> 148,295 half channels. Those each need refreshed gossip every two weeks. By
> default that would result in 90% channel updates. That we're seeing roughly
> three times as many channel updates vs node announcements compared to what's
> strictly required is maybe not that surprising. I agree, there would be a
> benefit to nodes taking a more active role in tracking calls to broadcast
> gossip.
>
> Thanks,
> Alex
>
> ------- Original Message -------
> On Wednesday, June 29th, 2022 at 6:09 AM, Michael Folkson
> <michaelfolk...@protonmail.com> wrote:
>
>> Thanks for this Alex.
>>
>> Here's a transcript of your recent presentation at Bitcoin++ on Minisketch
>> and Lightning gossip:
>>
>> https://btctranscripts.com/bitcoinplusplus/2022/2022-06-07-alex-myers-minisketch-lightning-gossip/
>>
>> Having followed Gleb's work on using Minisketch for Erlay in Bitcoin Core
>> [0] for a while now I was especially interested in how the challenges of
>> using Minisketch for Lightning gossip (node_announcement,
>> channel_announcement, channel_update messages) would differ to the
>> challenges of using Minisketch for transaction relay on the base layer.
>>
>> I guess one of the major differences is full nodes are trying to verify a
>> block every 10 minutes (on average) and so there is a sense of urgency to
>> get the transactions of the next block to be mined. With Lightning gossip
>> unless you are planning to send a payment (or route a payment) across a
>> certain route you are less concerned about learning about the current state
>> of the network urgently. If a new channel pops up you might choose not to
>> route through it regardless given its "newness" and its lack of track record
>> of successfully routing payments. There are parts of the network you care
>> less about (if they can't help you get to your regular destinations say)
>> whereas with transaction relay you have to care about all transactions
>> (paying a sufficient fee rate).
>>
>> "The problem that Bitcoin faced with transaction relay was pretty similar
>> but there are a few differences.For one, any time you introduce that short
>> hash function that produces a 64 bit fingerprint you have to be concerned
>> with collisions between hash functions. Someone could potentially take
>> advantage of that and grind out a hash that would resolve to the same
>> fingerprint."
>>
>> Could you elaborate on this? Why are hash collisions a concern for Lightning
>> gossip and not for Erlay? Is it not a DoS vector for both?
>>
>> It seems you are leaning towards per-peer sketches with inventory sets (like
>> Erlay) rather than global sketches. This makes sense to me and seems to be
>> moving in a direction where your peer connections are more stable as you are
>> storing data on what your peer's understanding of the network is. There
>> could even be centralized APIs which allow you to compare your current
>> understanding of the network to the centralized service's understanding. (Of
>> course we don't want to have to rely on centralized services or bake them
>> into the protocol if you don't want to use them.) Erlay falls back to
>> flooding if the set reconciliation algorithm doesn't work which I'm assuming
>> you'll do with Lightning gossip.
>>
>> I was also surprised to hear that channel_update made up 97 percent of
>> gossip messages. Isn't it recommended that you don't make too changes to
>> your channel as it is likely to result in failed routed payments and being
>> dropped as a routing node for future payments? It seems that this advice
>> isn't being followed if there are so many channel_update messages being sent
>> around. I almost wonder if Lightning implementations should include user
>> prompts like "Are you sure you want to update your channel given this may
>> affect your routing success?" :)
>>
>> Thanks
>> Michael
>>
>> P.S. Are we referring to "routing nodes" as "forwarding nodes" now? I've
>> noticed "forwarding nodes" being used more recently on this list.
>>
>> [0]: https://github.com/bitcoin/bitcoin/pull/21515
>>
>> --
>> Michael Folkson
>> Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
>> Keybase: michaelfolkson
>> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
>>
>> ------- Original Message -------
>> On Thursday, April 14th, 2022 at 22:00, Alex Myers <a...@endothermic.dev>
>> wrote:
>>
>>> 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@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
