avoid overloading invoiceParser with new payment identifiers while potentially long-running
resolve/finalize steps are ongoing, show errors inresolve/finalize steps to user.
given a bip21 uri that has both onchain addr and bolt11,
if we have LN enabled but no LN channels, auto-fallback to paying onchain
we will have to clean up and unify this logic between GUIs. becoming spaghetti :/
rumour has it, Thomas has a branch? :P
QEInvoice/QEInvoiceParser now properly split for mapping to Invoice type (QEInvoice)
and parsing/resolving of payment identifiers (QEInvoiceParser).
additionally, old, unused QEUserEnteredPayment was removed.
invoices are now never saved with user-entered amount if the original invoice
did not specify an amount (e.g. address-only, no-amount bip21 uri, or no-amount
lightning invoice). Furthermore, QEInvoice now adds an isSaved property so the
UI doesn't need to infer that from the existence of the invoice key.
Payments of lightning invoices are now triggered through QEInvoice.pay_lightning_invoice(),
using the internally kept Invoice instance. This replaces the old call path of
QEWallet.pay_lightning_invoice(invoice_key) which required the invoice to be saved
in the backend wallet before payment.
The LNURLpay flow arriving on InvoiceDialog implicitly triggered payment, this is
now indicated by InvoiceDialog.payImmediately property instead of inferrred from the
QEInvoiceParser isLnurlPay property.
I think we can re-enable the requests list, because requests
are now created explicitly by pressing the create request button.
Since this is an advanced feature, it should not be in the way of
people who do not want to see it. Here is a solution that might
work.
creating addresses beyond the gap limit.
- if lightning is enabled, propose to create a lightning-only invoice
- otherwise, propose to reuse an address
- never generate addresses beyond the gap limit
Implementation:
- createDefaultRequest is removed
- create_bitcoin_address is called whether the wallet has lightning
or not
and invoice has fallback address and amount can be paid on-chain.
In WalletMainView, follow on-chain payment path if available lighting balance is
insufficient for the invoice amount
