scenario:
- user opens a lightning channel and exports an "imported channel backup"
- user closes channel via local-force-close
- local ctx is published, to_local output has user's funds and they are CSV-locked for days
- user restores wallet file from seed and imports channel backup
- new wallet file should be able to sweep coins from to_local output (after CSV expires)
This was not working previously, as the local_payment_basepoint was not included in the
imported channel backups, and the code was interpreting the lack of this as the channel not
having option_static_remotekey enabled. This resulted in lnutil.extract_ctn_from_tx
using an incorrect funder_payment_basepoint, and lnsweep not recognising the ctx due to
the garbage ctn value.
The imported channel backup serialisation format is slightly changed to include the
previously missing field, and its version number is bumped (0->1). We allow importing
both version 0 and version 1 backups, however v0 backups cannot handle the above
described scenario (they can only be used to request a remote-force-close).
Note that we were/are setting the missing local_payment_basepoint to the pubkey of
one of the wallet change addresses, which is bruteforceable if necessary, but I
think it is not worth the complexity to add this bruteforce logic. Also note
that the bruteforcing could only be done after the local-force-close was broadcast.
Ideally people with existing channels and already exported v0 backups should re-export
v1 backups... Not sure how to handle this.
closes https://github.com/spesmilo/electrum/issues/8516
Note that for a required feature, BOLT-09 allows setting either:
- only the REQ bit
- both the REQ bit and the OPT bit
Hence, when checking if a feature is supported by e.g. an invoice, both
bits should be checked.
Note that in lnpeer.py, in self.features specifically, REQ implies OPT,
as it is set by ln_compare_features.
I believe this now implements all the checks listed in BOLT-02 for
update_add_htlc, however, the BOLT is sometimes ambiguous,
and actually the checks listed there IMO are insufficient.
There are still some TODOs, in part because of the above.
we were looking at inconsistent ctns
and we were looking at the wrong subject's ctx
all the FIXMEs and TODOs here will still warrant some attention.
(note that test_DesyncHTLCs was passing incorrectly:
the "assertRaises" was catching a different exception)
note: low R grinding would not have to be duplicated if we trusted the caller
to have done it already (as is the case with the classes in ecc.py), and if
we propagated the choice of "random_k" as part of the nonce_function passed
to libsecp256k1 (which is not currently done)
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)
