The sender suggests that the correct approach is to pre-sign multiple different transactions to cover various fee ranges. By increasing the fee by 2x each time and pre-signing 10 replacement transactions, a fee range of 1024x can be covered. It is mentioned that this approach can be further improved by increasing the multiplier towards the end of the range.

The sender emphasizes that increasing temporary storage and bandwidth costs by ~10x or even ~100x is not a significant concern in a highly scalable protocol like Lightning. They point out that there is no valid reason for B->C transactions to get stuck, and this issue reflects a major failing of the Lightning protocol that needs to be addressed.

Furthermore, the sender suggests that this fix should also be applied to other aspects of the Lightning protocol, such as channel opens. The email concludes with a link to Peter Todd's website (https://petertodd.org) and the sender's email address (peter@petertodd.org).