see code comment.
While the balance in the channels might shift before the sender tries to
pay the invoice, as we are not a forwarding node, that seems unlikely to matter.
It is the last Trampoline Forwarder that should be checked, not the
first one.
Consider route (of Trampolines only):
Alice-electrum -> T_ACINQ -> T_Hodlister -> Bob-electrum
Even if Bob has a transport open with ACINQ or even if Bob has a channel open with ACINQ,
Alice can safely use end-to-end trampoline for this route: ACINQ will not know who
the recipient is, so they will not try to do pay-to-open (and hold up the payment for minutes...).
related: https://github.com/ACINQ/lightning-kmp/pull/237
- better error handling: previously we stopped all attempts on any of
TRAMPOLINE_EXPIRY_TOO_SOON, UNKNOWN_NEXT_PEER, TEMPORARY_NODE_FAILURE.
Instead we should retry (but see code comments).
- previously payments failed if ALL of the following criteria applied:
- sender is paying via trampoline, but not via the ACINQ node (which is
special cased)
- receiver only has private channels and has put r_tags into invoice, along
with setting the trampoline feature bit in the invoice, however the receiver
is not connected to any trampoline forwarders directly
The sender would then assume that the private routing hints in the invoice
correspond to trampoline forwarders.
- also, previously if both the sender and the recipient used trampoline and
they shared a trampoline forwarder (that they were both connected to), the
private channels the recipient had (with nodes other than the shared TF)
would never be attempted.
This commit ports the work of EchterAgo and cculianu from Electron-Cash,
to implement a new toolchain to scan qr codes.
Previously, on Linux and Win, we have been using zbar to access the camera
and read qrcodes; and on macOS we used CalinsQRReader (an objective-C
project by cculianu).
The new toolchain added here can use QtMultimedia to access the camera,
and then feed that image into zbar. When used this way, zbar needs
fewer dependencies and is easier to compile, in particular it can be
compiled for macOS.
The new toolchain works on all three platforms, with some caveats
(see code comments in related commits) -- so we also keep the end-to-end
zbar toolchain; but at least we can drop CalinsQRReader.
The related changes in Electron-Cash are spread over 50+ commits (several PRs and direct
pushes to master), but see in particular:
https://github.com/Electron-Cash/Electron-Cash/pull/1376
some other interesting links:
b2b737001c163224cf1f3b31e0fcb1eda015908ehttps://github.com/Electron-Cash/Electron-Cash/pull/1545052aa06c23
- fix kivy wizard restore-from-seed
- qt seed dialog: disable "next share" if current share is invalid
- fix tests: file paths should not depend on $PWD (working dir)
was exiting with non-zero error code due to trying to copy directory
```
9cf9cdda331b565dd95b105d3fe987beefa113ac2c594d83783998017ad52d70 dist/electrum-4.1.4-16-g648fac709-portable.exe
020ceacb3a6fc5986d3ec271985c22c8646d2bb534536b8e2ab774924b21d58f dist/electrum-4.1.4-16-g648fac709-setup.exe
e65dbbe24fe01e8635d4def088667e65d4e9763e2ab74cbc1aec616b3f2834bc dist/electrum-4.1.4-16-g648fac709.exe
💬 INFO: Done.
cp: -r not specified; omitting directory '/home/user/wspace/electrum/contrib/build-wine/../../contrib/build-wine/fresh_clone/electrum/contrib/build-wine/dist/electrum'
```
Also update existing key with some signatures.
Now both keys have ThomasV's sig,
and they cross-sign each other.
I will use sombernight_releasekey to sign releases, and keep using the
older key to sign commits and other day to day stuff. As I use a separate
key to sign commits, the release key can be made hard to get to.
Imported wallets used to send change back to the "from address".
We keep this behaviour as default.
There has already been an option "Use change addresses" (exposed in GUI),
ignored so far by imported wallets (was only used by HD wallets).
With this change, imported wallets no longer ignore that option, and if set,
they will send change to a random unused imported address, instead of back to "from address".
If all addresses are used, it falls back to sending change back to the "from address".
see: https://github.com/spesmilo/electrum/pull/7330
see: https://github.com/spesmilo/electrum/issues/5353
Re get_change_addresses_for_new_transaction,
"allow_reuse" is a confusing parameter name:
it means whether we allow reusing already used change addresses to send new change to.
However, if the method returns [], we will instead reuse the "from address" and send change there.
So it quite unclear without thinking it through what "allow_reuse" means as it could be either
of the two (and they are ~opposite scenarios).
The new name is long but at least it is clear.
Previously if the wallet did not have a deterministic node id,
the wallet info dialog could say "lightning enabled, non-recoverable channels", but
the "recoverable channels" setting could be toggled and might even say "yes".
SomberNight
ThomasV
tiagotrs
Chris