AaronFiore/electrum
1
0
Fork 0
Code Activity

update release notes

Browse Source
This commit is contained in:
ThomasV
2022-08-05 12:59:05 +02:00
parent c421bdaff4
commit db794949ae
1 changed files with 46 additions and 38 deletions
Download Patch File Download Diff File Expand all files Collapse all files

84
RELEASE-NOTES
View File

@@ -1,43 +1,51 @@
# Release 4.3.0 - (not released yet) # Release 4.3.0 - (August 5, 2022)
This version introduces a set of UX modifications, that aim at * This version introduces a set of UI modifications that simplify the
simplifying the use of Lightning. The goal is to abstract payments use of Lightning. The idea is to abstract payments from the payment
from the payment layer, and to suggest solutions when a payment is layer, and to suggest solutions when a lightning payment is hindered
prevented by channel liquidity issues. by liquidity issues.
- Invoice unification: on-chain and lightning invoices have been
merged into a unique type of invoice, and the GUI has a single
'create request' button. Unified invoices contain both a
lightning invoice and an onchain fallback address.
- The receive tab of the GUI can display, for each payment
request, a lightning invoice, a BIP21 URI, or an onchain
address. If the request is paid off-chain, the associated
on-chain address will be recycled in subsequent requests.
- The receive tab displays whether a payment can be received using
Lightning, given the current channel liquidity. If a payment
cannot be received, but may be received after a channel
rebalance or a submarine swap, the GUI will propose such an
operation.
- Similarly, if channels do not have enough liquidity to pay a
lightning invoice, the GUI will suggest available alternatives:
rebalance existing channels, open a new channel, perform a
submarine swap, or pay to the provided onchain fallback address.
- A single balance is shown in the GUI. A piechart reflects how
that balance is distributed (on-chain, lightning, unconfirmed,
frozen, etc).
- The semantics of the wallet balance has been modified: only
incoming transactions are considered in the 'unconfirmed' part
of the balance. Indeed, if an outgoing transaction does not get
mined, that is not going to decrease the wallet balance. Thus,
change outputs of outgoing transactions are not subtracted from
the confirmed balance. (Before this change, the arithmetic
values of both incoming and outgoing transactions were added to
the unconfirmed balance, and could potentially cancel
eachother.)
- Invoice unification: on-chain and lightning invoices have been * In addition, the following new features are woth noting:
merged into a single invoice type. A invoice typically contains - support for the Blockstream Jade hardware wallet (#7633)
both a lightning invoice and an onchain fallback address. The GUI - support for LNURL-pay (LUD-06) (#7839)
has a single 'create request' button. - updated trampoline feature bit in invoices (#7801)
- the claim transactions of reverse swaps are not broadcast until
- The receive tab of the GUI can display, for each payment request, the parent transaction is confirmed. This can be overriden by
a lightning invoice, a BIP21 URI, or an onchain address. If the manually broadcasting the locakl transaction.
request is paid off-chain, the associated on-chain address will - the fee of submarine swap transactions can be bumped (#7724)
be recycled in subsequent requests. - better error handling for trampoline payments, which should
improve payment success rate (#7844)
- The receive tab displays whether a payment can be received using - channel backups are removed automatically when the corresponding
Lightning, given the current channel liquidity. If a payment channel is redeemed (#7513)
cannot be received, but may be received after a channel rebalance
or a submarine swap, the GUI will propose such an operation.
- For outgoing payments, if channels do not have enough liquidity to
pay a lightning invoice, the GUI will suggest available
alternatives: rebalance existing channels, open a new channel,
perform a submarine swap, or pay to the provided onchain fallback
address.
- A single balance is shown in the GUI. A piechart reflects how that
balance is distributed (on-chain, lightning, unconfirmed, frozen,
etc).
- The semantics of the wallet balance has been modified: only
incoming transactions are considered in the 'unconfirmed' part of
the balance. Indeed, if an outgoing transaction does not get
confirmed, that is not going to decrease the wallet balance. Thus,
change outputs of outgoing transactions are not subtracted from
the confirmed balance. (Before this change, the arithmetic values
of both incoming and outgoing transactions were added to the
unconfirmed balance, and could potentially cancel eachother.)
# Release 4.2.2 - (May 27, 2022) # Release 4.2.2 - (May 27, 2022)