The few other cases that used SimpleConfig.get_instance() now
either get passed a config instance, or they try to get a reference
to something else that has a reference to a config.
(see lnsweep, qt/qrcodewidget, qt/qrtextedit)
- This was added because we did not store the complete htlc history.
- It makes the result dependent on the current channel state
- That creates a race condition in sweep_info, because the result is cached.
- As a result, test_breach_with_spent_htlc was randomly failing.
"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
- 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
- add functions to lnsweep
- lnworker: analyze candidate ctx and htlc_tx
- watchtower will be optional
- add test for breach remedy with spent htlcs
- save tx name as label
- fix bug in lnsweep: lnwatcher transactions were indexed by prev_txid
- add test for breach remedy with unsettled htlcs
- add timeout option to lnpay, and replace DO_NOT_SETTLE with SETTLE_DELAY
so that we can read intermediate commitment tx in regtest
- use detect_who_closed; this allows us to redeem to_remote of breach ctx
- do not redeem to_local of breach ctx, because it is redundant with lnwatcher
- rename a few methods
in the case where an htlc is failed, it could happen
that we use the wrong list of htlcs to generate sweep
tx'es. we would use the pending list instead of the
committed list.
observed by sending 12300sat and then 123000sat,
the second payment fails and an AssertionError was
triggered cause the htlc output could not be found
in the ctx.
added some documentation to clarify the behaviour
of lnchan.included_htlcs.
SomberNight
ThomasV
Janus