Published on: 2021-02-23T12:33:50+00:00
The discussions surrounding the Lightning Network have been lacking a threat model or attacker profile. The primary concern is a griefing attack, where an attacker disrupts channels to capture traffic and command higher fees. It is believed that routing node operators in a gray area may execute these attacks.One proposed solution involves implementing a small anti-Denial of Service (DoS) fee, but there are concerns about the cost of closing and reopening channels compared to this fee. It was suggested that the original solution proposed in 2015, which involves closing out channels and sending back proof of closure, may be more effective.Another suggestion is for services to flag long-lived Hashed Time-Locked Contracts (HTLCs) and preferentially forward or reject them. However, determining the appropriate fee that deters attackers without increasing costs significantly is still a challenge.Efforts should be focused on ensuring that the network can gracefully degrade during turbulent periods, serving as a low-cost deterrence mechanism. Compensation for committing capital to Lightning itself could be provided through markets like Lightning Pool.Privacy concerns arise with incrementing hold fees along payment paths, as it could leak information about the distance between payer and payee. This makes it easier to associate payment parts with specific parties.Joost Jager has proposed a variation of bidirectional upfront payments that uses a time-proportional hold fee rate. Routing nodes advertise their hold fee rate and hold grace period. When an HTLC is resolved, the receiver pays the sender the hold fee rate minus hold fee discount. Joost provides an example calculation for a three-hop route to demonstrate the fees.There are concerns about the computation of hodl_fee_rate and the risk of going offline while holding an HTLC. A malicious upstream node could mimic offline status to inflate its due hold fee. Additionally, mobile clients may not charge hold fees, and sophisticated attackers might find ways to escape channel blacklist heuristics.In a conversation about feerates versus fixed fees, concerns were raised about the risks involved if a channel is forced on-chain. Antoine believes that despite these concerns, using feerates is an improvement and should be considered for a specification draft. He also mentions Stake Certificates as a better long-term solution for network economics without adding a new fee burden.Overall, the discussions highlight the importance of carefully considering the economic and security implications of proposed changes to the Lightning Network. Trade-offs between simplicity and flexibility need to be balanced while ensuring the network's viability and growth.The discussion centers around the debate between using feerates versus fixed fees in a scenario where a channel is forced on-chain. The concern is that if a channel is forced on-chain after an HTLC (Hash Time Locked Contract) is offered to another party, the transaction could remain in mempools until close to the timeout of the channel, leaving the party who offered the HTLC liable for a large amount of time. Fixed fees offer simplicity by bounding the risk for the offering party if their outgoing channel is dropped on-chain. However, variable fees may not fully cover the actual cost of the locked-up HTLC.Another issue is the vulnerability of channel jamming on the Lightning Network. A potential solution is bidirectional upfront payments, which involve using hold fees that are time-proportional instead of fixed to cover costs incurred during the lock-up period of an HTLC. In this system, routing nodes advertise their hold fee rate, and the receiver of the HTLC pays this fee minus a hold fee discount as compensation for the time the payment is held in flight. Routing nodes can only claim compensation if they delay forwarding the payment beyond a certain grace period. The sender of the payment constructs the onion payloads so that all nodes along the route have their costs covered.To address the limitation of expensive hold fees for applications like atomic onchain/offchain swaps, a variation of bidirectional upfront payments with a time-proportional hold fee rate is proposed. This hold fee rate compensates routing nodes for the time their outgoing HTLC is in flight and is communicated as part of their channel forwarding policy. The receiver of the HTLC primarily pays the hold fee, and routing nodes advertise their hold_grace_period to prevent anyone from collecting hold fees unconditionally. The update_add_htlc message is extended with hold_fee_rate and hold_fee_discount to coordinate the payment of fees. An example is given where every node charges 0.6 msat/sat/minute with a hold grace period of 1 minute.Overall, this proposal adds flexibility to fair pricing for hodl invoices and its applications while simplifying the parameter set. It aims to address the vulnerability of channel jamming on the Lightning Network and provides a potential solution for ensuring fair compensation for routing nodes and preventing excessive fees for HTLC lock-up periods.
Updated on: 2023-07-31T23:24:35.259454+00:00