htlcswitch: final settle signal (htlcswitch)

Host: joostjager  -  PR author: joostjager


  • Background information:


  • When an invoice is marked as settled in LND’s database (LookupInvoice rpc reports ‘SETTLED’), what is the state of the HTLC in the channel?
  • Suppose it would not be settled, what is the worst case possible outcome?
  • Describe a scenario in which this occurs. How likely is this to happen?
  • How do hodl invoices affect the likelihood of such scenarios happening?
  • Is it exploitable by an attacker? And if yes, how?
  • What does the settle flow look like for settle instructions received via the HTLC interceptor api?
  • How does #6517 attempt to fix the problem?
  • How can the new functionality be used to determine the final settle state of an invoice?
  • For how long does final settle information need to be kept on disk?
  • Is the final settle information stored in an efficient way?
  • Why is the final settle information stored in the same transaction that updates the channel state?
  • Why is a final settle event added to the HTLC notifier api?
  • Why is it necessary to add a new SUBSCRIBED event to the HTLC notifier event stream?
  • Is it useful to also store final failed states?
  • To what extent is there a problem for outgoing HTLCs too?