Hi list, Unfortunately we had some technical issues with the recording for Monday's call so we're going to have to rely on my memory (a severely corrupted data store). Thankfully, Clara jotted down some notes as well, but please chime in if you attended and we've missed something out!
Details for next call: * Monday 20 February * 18:00 UTC (possibly 19:00, be confirmed in a follow up email) * https://meet.jit.si/UnjammingLN * Agenda: https://github.com/ClaraShk/LNJamming/issues/3 # Meeting Summary 1. Proof of Forwarding We started the call with a discussion of the various "proof of forwarding" schemes that have been kicked around this mailing list in the past. Working of the assumption that upfront fees must always be sourced from the sender, we ran into similar issues around accumulated fees and differential rates even in the case where we have some proof of forward, because nodes can still choose to collaborate to "forward" a payment. Given the following topology and conditions: Alice ------ Bob ------ Carol ------ Dave ----- Evelyn * Alice is sending a payment to Evenlyn, a popular sink on the network. * Evenlyn has zero final-hop upfront fees (for simplicity's sake). * Bob and Carol are malicious actors, each charging 10 msat upfront. * Dave is an honest node with 4000 msat upfront fees (which is a rational upfront fee for a channel to a sink node that would have high success case fees). Using a proof of forward scheme where Alice places a secret in the _next_ node's onion which is required to claim upfront fees: * Bob may claim 4020 msat in upfront fees with a secret from Carol * Carol may claim 4010 msat in upfront fees with a secret from Dave * Dave may claim 4000 msat in upfront fees with a secret from Evelyn In the honest case, this nets out to 10 msat for Bob, 10 msat for Carol, and 4000 msat for Dave. In the dishonest case, Carol can disclose the forwarding secret to Bob, allowing them to claim the accumulated 4020 sat, then fail the payment anyway. We also spoke about the case where the downstream peer refuses to give up the secret, but this breakdown in cooperation is likely remedied by closing your channel. We didn't consider the case where upfront fees do not accumulate along the route, because this exposes us to a whole lot of (even worse) draining attacks. We once again discussed the complexity of this nature of jamming mitigation, how practical it would be to implement it and whether it is worthwhile pursuing if it will be an imperfect solution to upfront fee theft. 2. Upfront Fees + Attributable Errors The next point of discussion was the combination of upfront fees with attributable errors [1] to allow senders to more severely punish nodes that choose to steal upfront fees rather than forward the HTLC (due to the incentive issues noted in [2] when there are large fee differentials across the route). This led to a discussion about how effectively senders can enforce good upfront fee behavior - a question that remains open. We discussed: - Strict punishment of nodes that fail payments with upfront fees. - Sender side protections against selection of routes with incentive incompatible upfront fees. - The suboptimal, yet doable, solution of starting with an upper bound on upfront fees. This has the drawback of not properly compensating nodes that have a legitimate claim to high upfront fees because they face high opportunity cost. 3. Experimentation with Circuit Breaker We discussed the possibility of using circuit breaker[3] in the context of local reputation (or HTLC endorsement) in two different ways: (a) To begin surfacing the type of information that end users would require to decide to endorse a payment, and possibly automating that decision making. (b) In conjunction with an experimental TLV to add binary HTLC endorsement to update_add_htlc, though it was noted that this would require wider spread adoption of circuit breaker, because nodes that do not have it installed would not include the TLV on forwarding. This would also require LND changes to surface TLVs included with update_add_htlc on the interceptor API. As always, thank you to all that attended and hope to see ya'll in the next one! Best, Carla + Clara [1] https://github.com/lightning/bolts/pull/1044 [2] https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-January/003834.html [3] https://github.com/lightningequipment/circuitbreaker
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
