htlcswitch: attributable errors (htlcswitch)

Jun 8, 2023

https://github.com/lightningnetwork/lnd/pull/7139

Host: halseth  -  PR author: joostjager

Notes

• This PR is related to a proposed BOLT spec change, pr #1044
• The mailing list post provides more context.

Questions

• Let’s start with some basics. In the current spec:
  • Who is producing the error in case a payment fails?
  • What does the error message typically contain?
  • Who can read the error?
  • As a sender that just had a payment fail, what should you do on your next attempt?
• Problems with the current spec:
  • How can a malicious routing node producing an error negatively impact the sender?
  • How can a malicious routing node that did not produce the error negatively impact the sender?
  • What are the consequences for the sender?
• In addition to payments failing, maybe even worse are payments that are slow or even seemingly stuck. Is it possible for the sender to avoid slow nodes with today’s spec?
• Now to the “attributable errors” spec change proposal.
  • On a high level, what is it trying to solve?
  • How is this achieved?
  • That sounds pretty simple, why didn’t we just do this already? What makes that hard?
  • To overcome this last issue, this PR (and the spec proposal) does a clever trick that overcomes this (trading off some usable space in the onion). What is this “trick” (high-level)?
• Detailed (bonus) questions:
  • What’s the space complexity of the solution?
  • We can reduce this worst case space usage by half, how?
• Timestamp:
  • In addition to the error, a single data field is proposed added, what?
  • How can the sender use this field?
• How can the sender determine whether to use this feature?
• Assuming every node understands this new feature, how is it determined whether it should be used or not?
• Summing up:
  • What are the benefits of this proposal?
  • What are the downsides?