Author: Antoine Riard 2021-02-15 13:56:45
Published on: 2021-02-15T13:56:45+00:00
The discussion revolves around a new variation of bidirectional upfront payments that uses a time-proportional hold fee rate to address the limitation of not considering hold invoices and other long-term held packets. This "hodl_fee_rate" binds the hold fee to the effectively consumed timelocked period of the liquidity, reducing the number of parameters. However, routing nodes might still include the risk of hitting the chain in the computation of their `hodl_fee_rate`, and the corresponding cost of having onchain timelocked funds.To address these concerns, the proposal suggests that routing nodes advertise their `hold_grace_period` and accept an HTLC to forward only if they added a delay greater than `hold_grace_period` for relaying the payment and its response. However, there are concerns about the clock differences between endpoints of a channel and the risk of going offline while holding an HTLC. In this case, the `hodl_fee_rate` will be inflated until the counterparty goes back online, causing the routing node to be at loss. A malicious upstream node could mimic offliness to inflate its due hold fee, which could result in a cat-and-mouse game until it's obvious for a channel scoring logic that the peer is malicious and the channel must be closed.The discussion also touches on how nodes that do charge hold fees need to make sure to stay online; otherwise, peers may close channels with them because they are unreliable and charging for their own outage. Mobile clients might not charge hold fees, and it should happen rarely enough for this being an edge-case. However, a sophisticated attacker might be able to escape such channel blacklist heuristics. Finally, any packet which holds liquidity for a while should cover slot costs and timevalue, even if the value transferred is inferior to the final hold fees.In an email conversation between Antoine and Joost regarding the proposal to use feerates instead of fixed fees for Lightning Network transactions, concerns were raised about the potential risks involved if a channel is forced onchain. Antoine believes that despite these concerns, the proposal is still an improvement and should at least be considered for a specification draft. He also mentions the development of Stake Certificates as a better solution for long-term network economics without adding a new fee burden on payments.Joost points out that using fixed fees simplifies the parameter set and bounds the amount of risk in case the outgoing channel is dropped onchain. However, Antoine argues that the risk is bound in both cases and that capping the variable fee at a level that isn't considered risky may not fully cover the actual cost of the locked-up htlc. Additionally, any anti-DoS fee could turn out to be insignificant compared to the cost of closing and reopening a channel with the current state of the mempool.Overall, the discussion highlights the importance of carefully considering the economic and security implications of any proposed changes to the Lightning Network. While there may be trade-offs between simplicity and flexibility, it's important to find a solution that balances these factors while also ensuring the continued viability and growth of the network.
Updated on: 2023-06-03T03:46:34.059550+00:00