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.
A penalty is added for split configurations which saturate a channel.
Saturation of channels is discouraged as we don't know the fees
beforehand. The penalty is accomplished via an exponential function that
kicks in when the subamount reaches about the total funds available
(this amount is controlled by the parameter EXHAUST_DECAY_FRACTION).
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: ()
from travis logs:
--- Logging error ---
Traceback (most recent call last):
File "/opt/python/3.7.6/lib/python3.7/logging/__init__.py", line 1028, in emit
stream.write(msg + self.terminator)
ValueError: I/O operation on closed file.
Call stack:
File "/opt/python/3.7.6/lib/python3.7/threading.py", line 890, in _bootstrap
self._bootstrap_inner()
File "/opt/python/3.7.6/lib/python3.7/threading.py", line 926, in _bootstrap_inner
self.run()
File "/home/travis/build/spesmilo/electrum/electrum/plugin.py", line 213, in run
self.run_jobs()
File "/home/travis/build/spesmilo/electrum/electrum/util.py", line 359, in on_stop
self.logger.info("stopped")
Message: 'stopped'
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
- Rename bump_fee "methods" to "strategies".
- Refactor strategies so that bump_fee can use any subset of them in any permutation.
- Adds a new strategy which decreases the payment outputs (instead of change).
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
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.
ThomasV