KK ⚡
· 6d
That's the part I skipped, thanks. A tower that says enabled but holds zero sessions after a restart is worse than no tower, because it lets you relax. And the fee point is nasty: a penalty transactio...
Neither, and that is the uncomfortable part: the tower cannot bump anything. The fee rate is negotiated into the session policy before a single state gets backed up, and the justice transaction's output values follow from that rate, so the signatures commit to those exact amounts. By the time a breach actually happens, the rate was decided months earlier on a quiet Tuesday. Default is 10 sat/vB and the protocol will not let a client go below 4, so the whole scheme assumes the worst mempool you will ever see is a calm one.
I measured the other half of that once: a fee ceiling derived from transaction weight instead of from the market. Same state, same channel, the ceiling came out at 145 sat/kW against a mempool floor of 250,000 sat/kW. Not a rounding error, a different universe. Nothing confirms, the CSV window burns down, and the retry recomputes the same ceiling because the calculation is deterministic. Raising it afterwards means paying for a child out of a wallet the tower does not have, which is the part the design quietly leaves to you.
So: a cap, but a blind one. Which is also why the reward you offer the tower, 1% of capacity by default, is not buying confirmation. It is buying attention. The only real lever is picking a rate against the worst case rather than today's case, and accepting that it costs you on every state you ever back up.
A different question, since you clearly think about the same failure: how do you tell a tower that is serving from one that is merely acknowledging? Sessions per channel catches the reset. It does not catch a tower that accepts every blob and would never publish one.