On master fw_fail_htlc is, especially on the CI, flaky.
We mine 100 blocks, then wait fixed 5 seconds, then check if bob has
failed back the htlcs to alice.
However if the test runs slowly (CI) 5 seconds can be too short
for bob to catch up to the new 100 mined blocks.
Instead we should just use the wait_until_htlcs_settled helper function
which polls Alice local_unsettled_sent with 30 sec timeout, allowing bob
to take a bit longer (or be faster) than 5 s.
```
.***** test_fw_fail_htlc ******
initializing alice
funding alice
a101c8c4c22043ff42029bcab2f0bf6ce5482a60d656294cbec3a4df557e2687
initializing bob
funding bob
d323d572c54817116d185c91f15e449550c651eb4ed76891d3011e0a8eb4ef9a
initializing carol
funding carol
bbf3503663876a4ae00f70c7e58ad49318e83d5cf99d6effe692e113d10910c2
mining 1 blocks
starting daemon (PID 5559)
/tmp/alice/regtest/wallets/default_wallet
true
starting daemon (PID 5577)
/tmp/bob/regtest/wallets/default_wallet
true
starting daemon (PID 5595)
/tmp/carol/regtest/wallets/default_wallet
true
alice and carol open channels with bob
mining 3 blocks
wait until alice sees channel open.
wait until alice sees channel open..
wait until alice sees channel open...
alice pays carol
Daemon stopped
mining 1 blocks
mining 150 blocks
wait until 99ad1d44b9054f5a85c2fb45e9a9b93eb13c785104ed0664be5cf866d79d38fc:2 is spent.
...
wait until 99ad1d44b9054f5a85c2fb45e9a9b93eb13c785104ed0664be5cf866d79d38fc:2 is spent............................
mining 1 blocks
mining 100 blocks
alice htlc was not failed
FDaemon stopped
```
...so we can have multiple just in time channels with the same lsp.
We already save a remote scid alias in `on_channel_ready` which we
already have received after the new zeroconf channel is in open state.
So setting the alias to the static node id hash is counterproductive
because it doesn't allow to differentiate between channels.
Also extends the regtest (`just_in_time`) to do a second channel
opening, to cover this scenario. This doesn't add much runtime to
the test, so the cost seems reasonable.
Some regtest tests depend on manual fee injection to simulate certain
mempool conditions (e.g. lnwatcher_waits_until_fees_go_down). This is
done by manually injecting fee estimates into the `Network` object using
the `test_inject_fee_etas` cli command. However it can still happen that
the Network automatically updates its fee estimates from the connected
electrum server in the time between injecting the fee and the actual
tested logic making decisions based on the fee. This causes the test to
fail sometimes.
By setting the `test_disable_automatic_fee_eta_update` true the Network
will stop automatically updating the fee estimates and the test will
behave as expected.
'prepayment', which corresponds to the trusted part of the
lightning payment.
We use 2*sm.mining_fee, where 'mining_fee' is the flat part of
the server fee. However, future protocol should probably allow
to set a value that does not depend on 'mining_fee'.
(note that LND uses a hardcoded amount).
- CURRENT_WALLET is set when a single wallet is loaded in memory, and it
remains set after Electrum stops running.
- If several wallets are loaded at the same time, CURRENT_WALLET is unset,
and RPCs must specify the wallet explicitly (using --wallet for the CLI)
- The fallback to 'default_wallet' essentially only applies when
creating a new wallet file
This allows plugins to document the commands they add.
The docstring is parsed as a regular expression:
arg:<type>:<name>:<description>\n
Types are defined in commands.arg_types.
Note that this commit removes support for single letter
shortcuts in command options.
If a command is not properly documented, a warning is issued
with print(), because no logger is available at this point.
The class TxBatcher handles the creation, broadcast and replacement
of replaceable transactions. Callers (LNWatcher, SwapManager) use
methods add_payment_output and add_sweep_info. Transactions
created by TxBatcher may combine sweeps and outgoing payments.
Transactions created by TxBatcher will have their fee bumped
automatically (this was only the case for sweeps before).
TxBatcher manages several TxBatches. TxBatches are created
dynamically when needed.
The GUI does not touch txbatcher transactions:
- wallet.get_candidates_for_batching excludes txbatcher
transactions
- RBF dialogs do not work with txbatcher transactions
wallet:
- instead of reading config variables, make_unsigned_transaction
takes new parameters: base_tx, send_change_to_lighting
tests:
- unit tests in test_txbatcher.py (replaces test_sswaps.py)
- force all regtests to use MPP, so that we sweep transactions
with several HTLCs. This forces the payment manager to aggregate
first-stage HTLC tx inputs. second-stage are not batched for now.
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
ThomasV