Re: [Lightning-dev] LN Summit 2022 Notes & Summary/Commentary

2022-06-30 Thread Christian Decker
Matt Corallo writes: > On 6/28/22 9:05 AM, Christian Decker wrote: >> It is worth mentioning here that the LN protocol is generally not very >> latency sensitive, and from my experience can easily handle very slow >> signers (3-5 seconds delay) without causing too many issues, aside from >>

Re: [Lightning-dev] Onion messages rate-limiting

2022-06-30 Thread Christian Decker
Thanks Bastien for writing up the proposal, it is simple but effective I think. >> One issue I see w/ the first category is that a single party can flood the >> network and cause nodes to trigger their rate limits, which then affects >> the >> usability of the onion messages for all other

Re: [Lightning-dev] Gossip Propagation, Anti-spam, and Set Reconciliation

2022-06-30 Thread Michael Folkson via Lightning-dev
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

Re: [Lightning-dev] LN Summit 2022 Notes & Summary/Commentary

2022-06-30 Thread Matt Corallo
> On Jun 28, 2022, at 19:11, Peter Todd wrote: > > Idle question: would it be worthwhile to allow people to opt-in to their > payments happening more slowly for privacy? At the very least it'd be fine if > payments done by automation for rebalancing, etc. happened slowly. Yea, actually, I

Re: [Lightning-dev] Onion messages rate-limiting

2022-06-30 Thread Matt Corallo
One further note, I don’t think it makes sense to specify exactly what the rate-limiting behavior is here - if a node wants to do something other than the general “keep track of last forwarded message source and rate limit them” logic they should be free to, there’s no reason that needs to be

Re: [Lightning-dev] Onion messages rate-limiting

2022-06-30 Thread Bastien TEINTURIER
Thanks for your inputs! One issue I see w/ the first category is that a single party can flood the > network and cause nodes to trigger their rate limits, which then affects > the > usability of the onion messages for all other well-behaving parties. > But that's exactly what this proposal