htlcswitch: attributable errors (htlcswitch)

Host: halseth  -  PR author: joostjager



  • 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?