- fix regression in create_routes:
fwd_trampoline_onion was not added to the tuple
- fix onion structure for e2e
- maybe_fulfill_htlc:
check the mpp_status of the outer onion,
return trampoline_onion to be forwarded
We pass the private edges to lnrouter, and let it find routes end-to-end.
Previously the edge_cost heuristics didn't apply to the private edges
and we were just randomly picking one of the route hints and use that.
So e.g. cheaper private edges were not preferred, but they are now.
PathEdge now stores both start_node and end_node; not just end_node.
- trampoline node is the final recipient of MPP
- each trampoline receives a bucket of HTLCs
- if a HTLC from a bucket fails, wait for the entire bucket to fail
- move trampoline route and onion code into trampoline module
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.
- 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
ThomasV
SomberNight
bitromortac