Antoine Riard

> I also agree that a feature bit here will be useful but not for the dry_run but for the jamming mitigation itself. In this way, we can have a...

> Why would anyone set a feature bit that would result in less relays? The protocol should always be aligned with financial incentives. Latency as you don’t have to log...

> Previously, we would only calculate the time offset from the first 199 outbound peers that we connected to. This limitation is now removed, and we have a proper rolling...

> [Expected size of a commitment transaction](https://github.com/lightning/bolts/blob/master/03-transactions.md#expected-weight-of-the-commitment-transaction) is within (900 + 172 * 483 + 224) / 4 = 21050vB Check BOLT2’s `max_accepted_htlcs`, it’s 483 HTLC outputs in both directions...

> So maybe a better number is 42KvB or 50KvB. Yes, don’t forget the 2 * for anchor outputs. > Regardless of that, I think you shouldn't care about the...

> Still, what are TRUCs ? Do you have documentation ? TRUC = Topologically Restricted Until Confirmation, see https://github.com/bitcoin/bips/pull/1541

> Would this make things {broken, inconvenient} for potential users of TRUCs, e.g. by requiring swapping between v3 and v2? For historical lightning channel who have already negotiated parameters above...

I think 10kvb is okay as a limit though pray for someone telling it more to LN folks. There is very likely 2018 / 2019 channels open with `max_accepted_htlcs` at...

Oh awesome, starting to work on lightning-integration was in my week goals, I'm going to deep precisely in lightning-integration tomorrow to see exactly what we need to fit requirements. @jtimon...

sounds good to me for experimentation. historically been concerns about raising such limits for the worst-case computationally witness. some old conversations here: https://bitcoincore.reviews/21224