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.
Exclude unconfirmed transactions from --to_height and include them into --from_height.
The reason being that an unconfirmed transaction will end up eventually into the last
block which most of the time will be higher than --from_height
- trampoline is enabled by default in config, to prevent download of `gossip_db`.
(if disabled, `gossip_db` will be downloaded, regardless of the existence of channels)
- if trampoline is enabled:
- the wallet can only open channels with trampoline nodes
- already-existing channels with non-trampoline nodes are frozen for sending.
- there are two types of trampoline payments: legacy and end-to-end (e2e).
- we decide to perform legacy or e2e based on the invoice:
- we use trampoline_routing_opt in features to detect Eclair and Phoenix invoices
- we use trampoline_routing_hints to detect Electrum invoices
- when trying a legacy payment, we add a second trampoline to the path to preserve privacy.
(we fall back to a single trampoline if the payment fails for all trampolines)
- the trampoline list is hardcoded, it will remain so until `trampoline_routing_opt` feature flag is in INIT.
- there are currently only two nodes in the hardcoded list, it would be nice to have more.
- similar to Phoenix, we find the fee/cltv by trial-and-error.
- if there is a second trampoline in the path, we use the same fee for both.
- the final spec should add fee info in error messages, so we will be able to fine-tune fees
bump_fee was returning an invalid tx if its input was a
PartialTransaction that had signatures. It was relying on
line 1441 to remove signatures.
Relatedly, the WalletDB used to store such PartialTransactions as
PartialTransaction objects, but only until the program was restarted.
This is because serialising and de-serialising such a tx results in a
Transaction object.
So, combining these two, to reproduce a bug:
- create a tx, sign it, save as local
- bump fee, sign it, save as local
- bump fee --> tx already signed!? --> has old sigs, so it is invalid
Scenario (prior to change):
User opens wallet1 with 10k addresses, and then immediately opens wallet2
with 100 addresses.
wallet1 will synchronise first, fully, and only then will wallet2 start syncing.
Now, wallet1 and wallet2 will sync concurrently (and wallet2 will finish much
sooner as expected).
Previously, if bump_fee decided to add new inputs to the tx, they would
have a different sequence number than the existing inputs. This was
unintentional.
- raise OnionRoutingFailure whenever we want to fail a htlc
- catch that exception in htlc_switch
- this will avoid code duplication in the case of trampoline
Scenario (prior this change):
A task in lnpeer.Peer.taskgroup raises ORIG_EXC, e.g. in htlc_switch.
The taskgroup then cancels all its tasks and then awaits each (in cancel_remaining):
4e64c56042/aiorpcx/curio.py (L217-L221)
In Peer.main_loop, we would want ORIG_EXC to be raised,
but instead LightningPeerConnectionClosed() will be raised as
the Peer._message_loop() task is cancelled, and it is awaited first in cancel_remaining.
We should make sure that if a task is cancelled it will let the CancelledError
propagate out, or at least it does not raise a different exception instead.
