- better error handling: previously we stopped all attempts on any of
TRAMPOLINE_EXPIRY_TOO_SOON, UNKNOWN_NEXT_PEER, TEMPORARY_NODE_FAILURE.
Instead we should retry (but see code comments).
- previously payments failed if ALL of the following criteria applied:
- sender is paying via trampoline, but not via the ACINQ node (which is
special cased)
- receiver only has private channels and has put r_tags into invoice, along
with setting the trampoline feature bit in the invoice, however the receiver
is not connected to any trampoline forwarders directly
The sender would then assume that the private routing hints in the invoice
correspond to trampoline forwarders.
- also, previously if both the sender and the recipient used trampoline and
they shared a trampoline forwarder (that they were both connected to), the
private channels the recipient had (with nodes other than the shared TF)
would never be attempted.
Adds liquidity hints for the sending capabilities of routing channels in the
graph. The channel blacklist is incorporated into liquidity hints.
Liquidity hints are updated when a payment fails with a temporary
channel failure or when it succeeds. Liquidity hints are used to give a
penalty in the _edge_cost heuristics used by the pathfinding algorithm.
The base penalty in (_edge_cost) is removed because it is now part of the
liquidity penalty. We don't return early from get_distances, as we want
to explore all channels.
The test framework did not like the "Test" prefix.
```
electrum/tests/test_lnpeer.py:305
/home/travis/build/spesmilo/electrum/electrum/tests/test_lnpeer.py:305: PytestCollectionWarning: cannot collect test class 'TestSuccess' because it has a __init__ constructor (from: electrum/tests/test_lnpeer.py)
```
When forwarding an HTLC and the outgoing channel doesn't have
enough funds or other transient issues, we are failing the
HTLC with a temporary channel failure.
From BOLT #04:
* if during forwarding to its receiving peer, an otherwise unspecified,
transient error occurs in the outgoing channel (e.g. channel capacity
reached, too many in-flight HTLCs, etc.):
-> return a temporary_channel_failure error.
This is most useful when receiving MPP where there is a non-trivial chance
that we have received some HTLCs for a payment but not all, and the user
closes the program. We try to fail them and wait for the fails to get
ACKed, with a timeout of course.
similar to 05fd424548
from logs when running tests:
--- Logging error ---
Traceback (most recent call last):
File "...\Python39\lib\logging\__init__.py", line 1082, in emit
stream.write(msg + self.terminator)
ValueError: I/O operation on closed file.
Call stack:
File "...\Python39\lib\threading.py", line 912, in _bootstrap
self._bootstrap_inner()
File "...\Python39\lib\threading.py", line 954, in _bootstrap_inner
self.run()
File "...\Python39\lib\threading.py", line 892, in run
self._target(*self._args, **self._kwargs)
File "...\electrum\electrum\sql_db.py", line 71, in run_sql
self.logger.info("SQL thread terminated")
Message: 'SQL thread terminated'
Arguments: ()
The test failures corresponding to single-part (non-MPP) payments expose a bug.
see https://github.com/spesmilo/electrum/blob/196b4c00a35b288f28885c0ceb8afdd5ffbd9a0f/electrum/lnpeer.py#L1538-L1539
`lnworker.add_received_htlc` is not called for single-part payments...
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
- 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
SomberNight