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. "
```
storage encryption.
The password will be needed on startup with anchor channels.
Note that it remains possible to use non-encrypted storage
and keystore encryption with the command line.
- txins have an optional make_witness method
- instead of gen_tx, SweepInfo has a txin and
an optional txout, for 1st stage HTLCs
- sweep transactions are created by lnwatcher
The purpose of this change is to allow combining several
inputs in the same sweep transaction.
inspect_tx_candidate assumes that htlc transactions have
only one input, which is not true for anchor channels.
inspect_tx_candidate is still used by the watchtower, because
it does not have access to channel information.
Due to malleability of HTLC-transactions, we can't send presigned
justice transactions for the second-stage HTLC transactions, which is
why we now send first-stage justice transactions for anchor channels.
Due to anchor channel's sighash.SINGLE and sighash.ANYONECANPAY,
several HTLC-transactions can be combined. This means we must watch for
revoked outputs in the HTLC transaction not only at index 0 but at any
index.
