- Move 'handle_error_code_from_failed_htlc' to channel_db,
and call it from pay_to_route, because it should not be
called when HTLCs are forwarded.
- Replace 'payment_received' and 'payment_status'
callbacks with 'invoice_status' and 'request_status'.
- Show payment error logs in the Qt GUI
- In the invoices list, show paid invoices for which
we still have the log.
- use InvoiceInfo (NamedTuple) for normal operations,
because lndecode operations can be very slow.
- all invoices/requests are stored in wallet
- invoice expiration detection is performed in wallet
- CLI commands: list_invoices, add_request, add_lightning_request
- revert 0062c6d695 because it forbids self-payments
lnpeer (and interface) response-handling-code should not run in the
network main_taskgroup as the remote could force an exception
to be raised and that would kill the whole network instead of just the peer
e.g. Alice sends upd1, upd2, upd3, commitment_signed, upd4, upd5.
Bob receives all of these; and sends a revoke_and_ack but there is
a disconnect before Alice receives the revoke_and_ack.
During reestablish, if Bob claims to have received the commitment_signed,
Alice must not replay the msgs before that; but she should replay upd4 and upd5.
In recv_rev() previously all unacked_local_updates were deleted
as it was assumed that all of them have been acked at that point by
the revoke_and_ack itself. However this is not necessarily the case:
see new test case.
renamed log['unacked_local_updates'] to log['unacked_local_updates2']
to avoid breaking existing wallet files
Even if we haven't signed them yet (did not send commitment_signed).
Alternatively, if they are not yet signed, we could discard them here,
like we do already for remote updates above (chan.hm.discard_unsigned_remote_updates).
One of these two options must be done, and before this commit we were not doing either.
"current" used to be "oldest_unrevoked"; and pending was "oldest_unrevoked + 1"
but this was very confusing...
so now we have "oldest_unrevoked", "latest", and "next"
where "next" is "latest + 1"
"oldest_unrevoked" and "latest" are either the same or are offset by 1
(but caller should know which one they need)
rm "got_sig_for_next" - it was a redundant sanity check, that really
just complicated things
rm "local_commitment", "remote_commitment", "set_local_commitment",
"set_remote_commitment" - just use "get_latest_commitment" instead
Replay un-acked local updates (including commitment_signed) byte-for-byte.
If we have sent them a commitment signature that they "lost" (due to disconnect),
we need to make sure we replay the same local updates, as otherwise they could
end up with two (or more) signed valid commitment transactions at the same ctn.
Multiple valid ctxs at the same ctn is a major headache for pre-signing spending txns,
e.g. for watchtowers, hence we must ensure these ctxs coincide.
- remove remote_commitment_to_be_revoked
- pass old ctns to lnsweep.create_sweeptxs_for_watchtower
- store the ctn of sweeptxs in sweepStore database
- request the highest ctn from sweepstore using get_ctn
- send sweeptxs asynchronously in LNWallet.sync_with_watchtower
ThomasV