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)
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".
* Remove check for sign with privkey in init_cmdline
* Add with_privkey and with_wallet variants of signtransaction command
* Add unit tests for signtransaction_with_privkey and signtransaction_with_wallet commands
This is a regression from 64a931f21e,
which introduced "onchain_channel_backups", and renamed
the old "channel_backups" key to "imported_channel_backups".
The `save_backup` method was not changed to use the new "imported_channel_backups" key,
so the channel backups are in the backup file but they are ignored.
The "Batch RBF transactions" feature mutates existing "local" and "unconfirmed RBF"
transactions when creating new transactions: it simply adds the new outputs to the
existing txs (and updates the change).
The "RBF" flag is only enforced for unconfirmed txs, not for local txs.
The bug was that given a local LN funding tx, when creating a new channel
with "batch_rbf" enabled, we would modify the existing local tx, and
broadcast that.
related: #7298
auto import, add coolwallet S weird derivation path #7259
Would be nice to auto detect also coolwallet S derivation path.
In file bip39_wallet_formats.json :
{ "description": "coolwallet S derivation path using bip44 but with segwit script format",
"derivation_path": "m/44'/0'/0'",
"script_type": "p2wpkh-p2sh",
"iterate_accounts": true
}
see https://help.coolwallet.io/article/160-recover-btc-using-coolwallet-s-seed-without-the-wallet for their recovery instruction
SomberNight
tiagotrs
Chris
ThomasV
Nima
Thorsten Hempel
bitromortac
wakiyamap
Andrew Kozlik
jpph