htlcswitch: final settle signal (htlcswitch)
Host: joostjager -
- Background information: https://groups.google.com/a/lightning.engineering/g/lnd/c/Sfy_M9avQoU
- 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?