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