ThomasV reported contrib/release.sh generating .aab artifacts.
aabs are shady business... best to avoid handing privkeys to big G (or any 3rd party!).
This must be a consequence of the recent p4a rebase,
e.g. 04bb63bbf0
gui/qt/rbf_dialog.py (old) lines 57-64 were implementing logic that should not be part of GUI code.
Case in point, gui/qml/qetxfinalizer.py (old) lines 511-513 duplicated half of that logic but not the other half.
That logic is now moved to wallet.get_bumpfee_strategies_for_tx().
More context: a user on irc got confused when using the qml gui. They were sending "max" and wanted to bump_fee.
The qml gui selected the "preserve_payment" strategy by default, using which there was no solution, and the user
did not notice that the strategy can be altered (via the "method" dropdown). The qt gui had logic to select
"decrease_payment" by default in such a case (which does find a solution to bump) but this logic was not
duplicated in the qml gui.
Instead of duplicating the logic, this commit moves it to shared lib code.
avoid overloading invoiceParser with new payment identifiers while potentially long-running
resolve/finalize steps are ongoing, show errors inresolve/finalize steps to user.
- all forwarding types use the same flow
- forwarding callback returns a htlc_key or None
- forwarding info is persisted in lnworker:
- ongoing_forwardings
- downstream to upstream htlc_key
- htlc_key -> error_bytes
- a node scid alias is derived from the node ID
- the channel opening fee is sent in a TLV field of open_channel
- the server requires htlc settlement before broadcasting
(server does not trust client)
- split RequestForceClose and LocalForceClose options, as request force close is only available if connected.
- disable no close policy on dialog, as it locks the user in the dialog if no succesful close is initiated.
what this intended to do is keep the backing object QEChannelDetails alive until a result is obtained, to avoid
exceptions when emitting the result signal. this is now handled more robustly, the user can leave the dialog
without triggering exceptions later.
where the user has the preimage.
The CLTV requirements between old and new flow are imcompatible.
With the current locktime value, the server was vulnerable to an
attack where the client does not settle the lightning payment
and claims a refund. In order to support both old and new flows,
one would need to use different locktimes.
SomberNight
Sander van Grieken
ThomasV