Handles `UserFacingException` in the `WCWalletPasswordHardware` step of
the hardware wallet wizard flow. This fixes the previous FIXME and
prevents the crash reporter from getting triggered if the the user e.g.
disconnects his hardware wallet during the wallet encryption step.
Throws UserFacingException if the communication with the ledger fails
due to an OSError. This happens e.g. if the Bitcoin app has been closed.
We shouldn't get crash reports for errors due to disconnection.
Deduct the just in time channel opening fees from the total amount so
htlcs don't get timed out if they come from a just in time channel with
opening fee.
Related: https://github.com/spesmilo/electrum/pull/9584
Calling dnssec.query() with missing "cryptography" dep behaves the same as if DNSSEC validation failed: validated=False will be returned.
When used for openalias, we mandate validated=True.
Allows replacing a saved `PaymentInfo` of `SENT` direction if the old
one is not yet paid.
This allows the user to retry paying a 0 amount invoice with different
amount if the previous attempt failed.
Allows storing two different payment info of the same payment hash by
including the direction into the db key.
We create and store PaymentInfo for sending attempts and for requests (receiving),
if we try to pay ourself (e.g. through a channel rebalance) the checks
in `save_payment_info` would prevent this and throw an exception.
By storing the PaymentInfos of outgoing and incoming payments separately in
the db this collision is avoided and it makes it easier to reason about
which PaymentInfo belongs where.
I was unable to do a "Max" amount submarine swap because the
`fee_estimate` method used by `LNWallet.num_sats_can_send()` uses a
hardcoded `fee_proportional_millionths` to estimate the fee for the
lightning payment.
When the actual fee determined later is higher
than the estimated fee the payment fails as the channel is unable to add
the htlc sum including the real fees as the amount exceeds the balance of
the channel.
Using the fees the maximum fees user has configured and estimate the
potential fee as inverse of PaymentFeeBudget is more
reliable/conservative as we definitely aren't going to pay more fees
than this amount.
When moving the lightning fee slider in the SettingsDialog by clicking
on the range instead of pulling the slider the new fee value wouldn't
get stored in the config as the sliderRelased signal is only emitted
when the slider is pulled.
This change updates it on valueChanged.
Use the `OnionFailureCode.INVALID_ONION_VERSION` (BADONION | PERM | 4)
code when sending back `update_fail_malformed_htlc` as just sending a plain
`BADONION` is not explicitly mentioned as correct in the spec.
Splits `LNWallet.dont_settle_htlcs` into `LNWallet.dont_settle_htlcs`
and `LNWallet.dont_expire_htlcs`.
Registering a payment hash in dont_settle_htlcs will prevent it from
getting fulfilled if we have the preimage stored. The preimage will not
be released before the the payment hash gets removed from
dont_settle_htlcs. Htlcs can still get expired as usual or failed if no
preimage is known.
This is only used by Just-in-time channel openings.
Registering a payment hash in dont_expire_htlcs allows to overwrite the
minimum final cltv delta value after which htlcs would usually get
expired. This allows to delay expiry of htlcs or, if the value in the
dont_settle_htlcs dict is None, completely prevent expiry and let the
htlc get expired onchain.
Splitting this up in two different dicts makes it more explicit and
easier to reason about what they are actually doing.
Please enter the commit message for your changes. Lines starting
It seems useful to report exceptions happening in the htlc_switch to the
crash reporter as it shouldn't raise exceptions in theory and this could
help catch subtle bugs.
refactor `htlc_switch` to new architecture to make it more robust
against partial settlement of htlc sets and increase maintainability.
Htlcs are now processed in two steps, first the htlcs are collected into
sets from the channels, and potentially failed on their own already.
Then a second loop iterates over the htlc sets and finalizes only on
whole sets.
# Conflicts:
# electrum/lnpeer.py
Add unittest to TestPeerForwarding which sends a multi trampoline
payment.
Wait another htlc_switch iteration in tests because trampolines might have different delays
There is a race when initiating multiple lightning payments concurrently
(e.g. when doing a reverse swap with prepayment + swap payment).
suggest_splits might overallocate
split amounts for a channel as the splitting of both invoice amounts runs
concurrently and before acutal htlcs that reduce the channels balance
have been added to the channel yet. This results in a "not
enough balance" PaymentFailure once we try to send the htlcs and the
other payment attempt already reduced the available balance of the
channel.
This fix takes a lock from splitting the amount until the htlcs are
put on the channel, so suggest_splits always acts on the correct channel
balance.
f321x