Counter-intuitively, the motivation is to be able to *send* more htlcs,
for MPP trickery. We don't offer more htlcs than this limit, to be
conservative with what we send, and to interoperate with clightning.
defaults of other clients:
eclair: 30
clightning: 30
lnd: 483
- 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
- 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
- LNWorker is notified about htlc events and creates payment events.
- LNWorker._pay is a while loop that calls create_routes_from_invoice.
- create_route_from_invoices should decide whether to split the payment,
using graph knowledge and feedback from previous attempts (not in this commit)
- data structures for payment logs are simplified into a single type, HtlcLog
Upfront shutdown script is a script provided on channel opening,
which will be used by the peer to enforce us closing to this script
on collaborative channel close.
If we get a revack after reestablish, but the fail_htlc was already
committed in a previous app-session, the fail_htlc will not be re-sent and
we will not have the reason (as it's not persisted).
fixes#6675
- Use change addresses (instead of receive) for the static_remotekey to_remote outputs,
and reserve these to greatly reduce the chance of address-reuse
- Use change addresses (instead of receive) for LN channel sweep addresses.
Note that these atm are not getting reserved.
transitions, and actions taken as a result.
- state transitions are performed in lnchannel.update_onchain_state()
- peer actions are in LNWorker.on_channel_update()
