V3 transaction policy for anti-pinning

moving discussion here…

Again, I am not denying that there is a 100x reduction in the hypothetical situation of transaction pinning. What I am pointing out is that Lightning already fixed that transaction pinning problem with the design of anchor channels, making your 100x reduction irrelevant.

If an adversary splits the view of which commitment transaction is broadcasted, the remote copy can become the pin since the defender is unable to propagate their spend of the remote commit tx anchor(as their peers do not have the remote commit tx)

But even that is actually incorrect: the highest feerate you could ever possibly need is the one where all of your balance in the channel goes to fees.

I don’t think that’s correct. As a simplified motivating example, if we set reserve amounts to 0, if you want to send “all” your funds, your top feerate will be zero, even if the total funds recoverable in timeout would be all your remaining liquidity.

I’m sure there are ways to mitigate this, like capping total HTLC exposure as a % of liquidity, but it’s pretty clearly a reduction in functionality? Possibly completely broken as it implies that you can never drain your liquidity completely to reserve levels?