fix "Automated BIP39 recovery" not scanning change paths. Imported wallets: fix delete_address removing too many txs. during LN chan open, do not backup wallet automatically. fix LN error/warning message-handling, and fix regression that errors during channel-open were not properly shown in GUI. fix duplication of some OS notifications on onchain txs. some improvements for high-DPI monitors. more resilient startup: better error-handling and fallback. macOS: fix opening "Preferences" segfaulting for some. Linux: fix os.chmod when running in tmpfs on Linux. The "source-only" tarball excludes compiled locale files, generated protobuf files, and does not vendor our runtime python dependencies (the packages/ folder). Source-only: we now also distribute a "source-only" Linux-packager-friendly tarball, in addition to the current "normal" tarball. Appimage: fix AppImage failing to run on certain systems. Appimage: fix the "-portable" flag for AppImage, and for pip installs. windows: bump pyinstaller to 4.10 and wine to 7.0. (note these include a fix to an openssl DOS-vector CVE-2022-0778) bump bundled Python version (win, mac, appimage) to 3.9.11, (android) to 3.8.13. Win8.1 still works but only Win10 is regularly tested. Existing users can keep using version 4.1.5 for now, but should consider upgrading or changing their OS. Version 4.2.0 already unintentionally broke compatibility with Win7 and there is no easy way to restore and maintain support. Windows: we are dropping support for Windows 7. (Before this change, the arithmetic values of both incoming and outgoing transactions were added to the unconfirmed balance, and could potentially cancel each other.) Thus, change outputs of outgoing transactions are not subtracted from the confirmed balance. Indeed, if an outgoing transaction does not get mined, that is not going to decrease the wallet balance. The semantics of the wallet balance has been modified: only incoming transactions are considered in the 'unconfirmed' part of the balance. A pie chart reflects how that balance is distributed (on-chain, lightning, unconfirmed, frozen, etc). 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. 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. The receive tab displays whether a payment can be received using Lightning, given the current channel liquidity. If the request is paid off-chain, the associated on-chain address will be recycled in subsequent requests. The receive tab of the GUI can display, for each payment request, a lightning invoice, a BIP21 URI, or an onchain address. Unified invoices contain both a lightning invoice and an onchain fallback address. 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. The idea is to abstract payments from the payment layer, and to suggest solutions when a lightning payment is hindered by liquidity issues:
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |