Thank you for taking the time to summarize this discussion.
As you mention, there is a fundamental trade-off between performance (latency) and privacy. While there may be a slight privacy improvement, I’m more concerned that this amplifies performance issues that already exist in Lightning today. Adding a forwarding delay effects every hop of every payment attempt. Not only does this slow the delivery of successful payments by delay * hop_count, but perhaps more concerning is it also delays failing payment attempts, both legitimate and malicious. As routing relies on trial-and-error, failed payments are expected. Worse yet, probing is a common trick to improve future reliability, which means we can expect the number of failed payments to grow exponentially with the number of nodes on the network. Adding delays to these failed attempts compounds the problem of locked liquidity and HTLC slots for routing nodes.
So I agree, routing nodes have no incentive to follow these rules, other than as an optional feature to attract privacy-focused nodes.
I like your idea of applying delays at the source and destinations:
- It’s opt-in and can be tuned to the user’s preference
- It’s doesn’t require protocol changes
- For the receiver, it’s safe to consider the payment successful, even while delaying HTLC fulfillment