Carla Kirk-Cohen [ARCHIVE] on Nostr: 📅 Original date posted:2023-02-08 📝 Original message: Hi list, Unfortunately we ...
📅 Original date posted:2023-02-08
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230208/c383d310/attachment.html>;
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230208/c383d310/attachment.html>;