onchain invoice payments should warn if payment after expiry about lightning HOT 4 OPEN

One way to do this would be to:

• add new states: "underpaid" and "overpaid" (and "unconfirmed")
• update the amount_received and increment the updated_index for the event; any amount paid should mark the invoice as paid
• if an invoice is marked as paid but the amount_received is less than amount, a lightning payment should be accepted (and the amount_received added to)

Any client watching for payment attempts etc will be able to inspect the "amount" vs the "amount_received" fields and will be notified of updates to the event due to the updated_index changing.

If an invoice gets paid twice: same logic. Update the amount_received and increment the updated_index.

The bookkeeper can keep a log of all the independent onchain/in-channel events that contributed to the payment of that invoice, which can be inspected later (or programatically by an app/client).

The app that's operating on top can take action to notify a client/user/administrator of payments that need attention (refunds, etc).

States an invoice can be in:

unpaid
unconfirmed (TODO)
underpaid, amount_received < amount
paid, amount_received == amount
overpaid, amount_received > amount
expired

Payments can move from

unpaid -> underpaid -> paid -> overpaid
unpaid -> expired
unpaid -> expired -> (onchain only!) underpaid -> paid -> overpaid (rcv > amt)

if underpaid && !expired -> LN payment allowed
if underpaid && expired -> LN payment not allowed (requires second invoice)

Alternately: we could not include overpaid as a state, and just use the amount_received field to figure out if a refund is owed? This would happen in a client/calling app, not CLN.

from lightning.

For item 1:

2023-10-31T20:38:48.105Z UNUSUAL lightningd: On-chain payment received for expired invoice with label label3. Outpoint for received payment: dcc98acced809a4c59a30faa1f0e869271de2f096e6b0e010008ad512950386b:1

Look good? ^

As for item 2, how would i determine if an invoice has been paid expired? Should I store something in the db, either in the invoice_fallbacks table (new column) or the invoices table (new status / column)? Or I could also generate this field dynamically by joining the wallet txs with the invoices table?

from lightning.

We can also address the scenario of underpayments here

from lightning.

Both issues could be addressed by adding new statuses to the status enum on the invoices table, eg: PAID_EXPIRED and UNDERPAID

from lightning.