A few notes on the difference between dynamic and static fee approaches:

• Dynamic fee-bumping (ignoring pinning attacks) has higher operational cost (watchtower wallet management consumes non-negligible amounts of bitcoin). It's not clear if the static fees approach will overall cost more due to high over-payments or not.
• In both approaches, it's possible that the highest possible Cancel fee-rate is insufficient. In this rare circumstance, with dynamic fee-bumping a WT can be refilled by any participant, with static fee-bumping a new Cancel TX needs to be signed by all stakeholders.
• Dynamic fee-bumping has higher hot-wallet risk (each WT wallet requires of the order 0.01-0.1 BTC depending on the use case) and could be impractical for small-scale use cases. Static fee-bumping requires WT wallet and thus enables smaller-scale use cases.

Implementing Static fees approach:

• I'd argue it's also necessary to support multiple (static) fee-rates for the Emergency and Unvault Emergency TXs too. WDYT?
• Is it feasible to batch sign (one-click) these txs, where the user sees on their hardware wallet screen something like Cancel TX, feerates = [5, 10, 100, 1000, 5000] sats/vByte?
• What are the limits of signature storage on the hardware wallet?
• What is the communication burden of all the excess signatures? How many signatures can be supported per cancel tx?
• I think we have a reasonable range for the fee-rates from the data in the fee-bump research. The CUMMAX95Q90 is still a reasonable maximum IMO. The more fee-rates can be included between the min and the max, the less will be lost to over-payments. But this has practical limits based on storage and communication overhead which need to be computed.

In both approaches, it's possible that the highest possible Cancel fee-rate is insufficient. In this rare circumstance, with dynamic fee-bumping a WT can be refilled by any participant, with static fee-bumping a new Cancel TX needs to be signed by all stakeholders.

The most important point here is that the "reserve feerate" (maximum feerate assumed to ever happen while we need to Cancel all our delegated vaults) is flexible and unilateral with dynamic fee bumping, whereas with pre-signing multiple versions of the transaction it's bound to for the entire duration of the deployment.

I'd argue it's also necessary to support multiple (static) fee-rates for the Emergency and Unvault Emergency TXs too. WDYT?

I don't think so. For the Emergency we should always pay the maximum feerate. It's a situation that should not happen and we should not rely on the watchtowers to try transactions paying lower fees first.

Is it feasible to batch sign (one-click) these txs, where the user sees on their hardware wallet screen something like Cancel TX, feerates = [5, 10, 100, 1000, 5000] sats/vByte?

It's a requirement, but not for the feerates values. Those values should be set on the signing device during the ceremony and we trust it to enforce this.

What are the limits of signature storage on the hardware wallet?

I don't understand? The signing device does not store the signatures, it signs?

What is the communication burden of all the excess signatures? How many signatures can be supported per cancel tx?

The sig message between the stk and the wt is going to be refactored. So that'd be pretty much the encoding of N more signatures in JSON.
I think we'd refactor the sigs for the coordinator in a similar way.

I think we have a reasonable range for the fee-rates from the data in the fee-bump research. The CUMMAX95Q90 is still a reasonable maximum IMO

I agree. We could even go above that since this does not put a requirement on funding per WT.

The more fee-rates can be included between the min and the max, the less will be lost to over-payments

Yes. I believe for this part we can say that a Cancel taking place is a rare event which surely demonstrates a mis-configuration. As such, the cost is very asymetric: you might never pay the fee cost (or you do only very rarely), but you always pay the storage, communication, and computation cost. I'd therefore be in favour of larger steps (like 100sats/vb).

It was discussed during the meeting, and i think [10, 100, 200, 400, 800] sounds good.