Hi ZmnSCPxj, Not quite up-to-speed back into this, but, I believe an issue with using > feerates rather than fixed fees is "what happens if a channel is forced > onchain"? > > Suppose after C offers the HTLC to D, the C-D channel, for any reason, is > forced onchain, and the blockchain is bloated and the transaction remains > floating in mempools until very close to the timeout of C-D. > C is now liable for a large time the payment is held, and because the C-D > channel was dropped onchain, presumably any parameters of the HTLC > (including penalties D owes to C) have gotten fixed at the time the channel > was dropped onchain. >
The simplicity of the fixed fee is that it bounds the amount of risk that C > has in case its outgoing channel is dropped onchain. > The risk is bound in both cases. If you want you can cap the variable fee at a level that isn't considered risky, but it will then not fully cover the actual cost of the locked-up htlc. Also any anti-DoS fee could very well turn out to be insignificant to the cost of closing and reopening a channel with the state of the mempool these days. Joost
_______________________________________________ Lightning-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
