- use_recoverable_channel is a user setting, available
only in standard wallets with a 'segwit' seed_type
- if enabled, 'lightning_xprv' is derived from seed
- otherwise, wallets use the existing 'lightning_privkey2'
Recoverable channels:
- channel recovery data is added funding tx using an OP_RETURN
- recovery data = 4 magic bytes + node id[0:16]
- recovery data is chacha20 encrypted using funding_address as nonce.
(this will allow to fund multiple channels in the same tx)
GUI:
- whether channels are recoverable is shown in wallet info dialog.
- if the wallet can have recoverable channels but has an old node_id,
users are told to close their channels and restore from seed
to have that feature.
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 re the channel update for the incoming direction of our own channels.
This message can only come from the counterparty itself so maybe the sig check
is redundant... but for sanity I think we should check it anyway.
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.
The test failures corresponding to single-part (non-MPP) payments expose a bug.
see 196b4c00a3/electrum/lnpeer.py (L1538-L1539)
`lnworker.add_received_htlc` is not called for single-part payments...
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
- 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
- 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
SomberNight
ThomasV
bitromortac