force-closed. Assert final balance in lnworker.get_history().
If we offered some HTLCs, we do not know yet whether they will be
redeemed by us or by the remote.
ref https://github.com/spesmilo/electrum/pull/9189
```
Traceback (most recent call last):
File "/home/user/wspace/electrum/electrum/gui/qt/my_treeview.py", line 166, in on_commitData
self.tv.on_edited(idx, edit_key=edit_key, text=new_text)
File "/home/user/wspace/electrum/electrum/gui/qt/history_list.py", line 699, in on_edited
self.hm.update_fiat(index)
File "/home/user/wspace/electrum/electrum/gui/qt/history_list.py", line 371, in update_fiat
self.dataChanged.emit(idx, idx, [Qt.ItemDataRole.DisplayRole, Qt.ForegroundRole])
AttributeError: type object 'Qt' has no attribute 'ForegroundRole'
```
add space
add gossip address field serialization, parsing and tests
fix linter
consolidate tests, fix intendation
refactor test in loops
add gossip address field serialization, parsing and tests
Ideally, given an on-chain backup, after the remote force-closes, we should be able to spend our anchor output,
to CPFP the remote commitment tx (assuming the channel used OPTION_ANCHORS).
To spend the anchor output, we need to be able to sign with the local funding_privkey.
Previously we derived the funding_key from the channel_seed (which comes from os.urandom).
Prior to anchors, there was no use case for signing with the funding_key given a channel backup.
Now with anchors, we should make its derivation deterministic somehow, in a way so that it can
be derived given just an on-chain backup.
- one way would be to put some more data into the existing OP_RETURN
- uses block space
- the OP_RETURNs can be disabled via "use_recoverable_channels"
- only the initiator can use OP_RETURNs (so what if channel is in incoming dir?)
- instead, new scheme for our funding_key:
- we derive the funding_privkey from the lnworker root secret (derived from our bip32 seed)
- for outgoing channels:
- lnworker_root_secret + remote_node_id + funding_tx_nlocktime
- for incoming channels:
- lnworker_root_secret + remote_node_id + remote_funding_pubkey
- a check is added to avoid reusing the same key between channels:
not letting to user open more than one channel with the same peer in a single block
- only the first 16 bytes of the remote_node_id are used, as the onchain backup OP_RETURNs only contain that
- as the funding_privkey cannot be derived from the channel_seed anymore, it is included in the
imported channel backups, which in turn need a new version defined
- a wallet db upgrade is used to update already stored imported cbs
- alternatively we could keep the imported cbs as-is, so no new version, no new funding_privkey field, as it is clearly somewhat redundant given on-chain backups can reconstruct it
- however adding the field seems easier
- otherwise the existing code would try to derive the funding_privkey from the channel_seed
- also note: atm there is no field in the imported backups to distinguish anchor channels vs static-remotekey channels
The qtmultimedia-based qrreader has the concept of "strong_count":
before the scanner returns a decoded qr code result, it waits until
it has seen at least "strong_count" (e.g. 10) frames in which the qr code was seen and successfully decoded.
I think the idea might have been to reduce false positives, mis-decoding qr codes from bad frames.
However in practice it makes scanning even moderately sized qr codes really difficult for the user:
it takes several seconds (at least on my laptop cam) to obtain enough "clear" frames that count into the strong_count.
So I am lowering the strong_count to 2, down from CAMERA_FPS/3,
which makes it easier to scan, and I still haven't seen false positives even with this value.
Previously calling add_transaction with a malformed Transaction obj could
result in an exception late in the flow, after the walletdb was already side-effected.
Rollback of such side-effects is not implemented :/
but this small patch should at least cover and prevent some common cases.
```
File "/opt/electrum/electrum/address_synchronizer.py", line 358, in add_transaction
self.db.add_transaction(tx_hash, tx)
File "/opt/electrum/electrum/json_db.py", line 42, in wrapper
return func(self, *args, **kwargs)
File "/opt/electrum/electrum/wallet_db.py", line 1434, in add_transaction
tx = tx_from_any(str(tx))
File "/opt/electrum/electrum/transaction.py", line 1339, in tx_from_any
raise SerializationError(f"Failed to recognise tx encoding, or to parse transaction. "
```
