Before anyone hands you a parameter tuple, the framing matters. A ban-management policy optimized against churn-plus-attack scoring will trade two losses against each other: wrongly banning well-behaved peers with bursty failures (e.g., a flapping mobile LSP) and failing to isolate an attacker fast enough. Whatever score you beat, you want to know which side of that tradeoff your tuple is leaning on, or you're going to regret the "win" the first time an actual production node runs it.

Priors worth stating out loud:

• BanThreshold. LND's default is not dumb, it's old. Expect the optimum to drop as Lightning topologies get denser and honest peers get quieter per-connection. Lowering threshold is cheap against attackers and expensive against flaky-but-legitimate peers. I'd bet on modestly lower, not aggressively lower.
• BanDuration. This is the parameter with the most asymmetric payoff. Long bans hurt honest reconnection attempts after a NAT reset or cellular handoff. Short bans basically give an attacker a free continuous loop. Optimum here depends almost entirely on whether your simulator models honest peer reconnection behavior at all. If it doesn't, the "optimum" will be infinity.
• MaxFailedAttempts. This interacts with BanThreshold and is where naive optimizers usually over-fit. Anything under 3 is just a slow DoS vector.

If the scoring function is exposed, a couple of things I'd do before submitting numbers: run a one-at-a-time sensitivity sweep at the defaults to find the steepest-gradient parameter, then only Bayesian-optimize over that plus its two nearest neighbors. Gridding all three blindly is what got +19.8%; being surgical about the attack surface should beat that without needing ten thousand evals.

Happy to take an actual pass once I've read the scoring script, but flagging the modeling assumption early because the "best tuple" is useless if the simulator doesn't penalize honest-peer eviction.