- implement it specifically for the "singlesig trezor" case
- aimed to be generic enough that support for more complex scripts
and other keystores could be added later
user on bitcointalk [0] tried to create wallet with name "w/o 2FA".
Before this, one would only get an error after the last page of the wizard.
With this, the "Next" button does not even get enabled if the name does not look ok.
(and as in comment, maybe we should be even stricter re what is allowed)
[0]: https://bitcointalk.org/index.php?topic=5483514.msg63584789#msg63584789
fixes https://github.com/spesmilo/electrum/issues/8837
Alternatively we could do a config upgrade (convert_version_*) to fix that specific issue,
but they are not safe against downgrade-upgrade-again, so probably not the best choice for
crash-inducing values.
And this kind of converter is a generic solution that can be useful for other configvars later
(though for most usages I expect we will also need a converter for the setter).
fixes https://github.com/spesmilo/electrum/issues/8813
regression from eef9680743
We started setting the witness field in above commit to be able to provide the witnesses for already pre-signed
external inputs to the device, e.g. for a coinjoin.
Trezor One fw has pretty strict limits on the witness field: max 109 bytes,
probably because that's a ~tight upper bound for a p2wpkh witness:
<num_witness_items> <len(sig)> <sig> <len(pubkey)> <pubkey>, it comes out to 3+73(high-S and high-R)+33.
ed1785a985/legacy/firmware/protob/messages-bitcoin.options (L35)
Trezor model T seems to have higher limits.
tx_inputs is called for the tx being signed (for_sig=True), and for its parents/prev_txes (for_sig=False).
The witness is only useful for the tx being signed, I think.
Users reported seeing a "DataError: bytes overflow" exception when using a Trezor One to sign 2of3 p2wsh multisig txs.
There were no external inputs involved so for the tx being signed all witnesses were None, however we were also
setting the witness for the inputs of prev_txes.
The witness for a 2of3 pw2sh multisig input is around ~253 bytes.
To sidestep the problem, we now only set the witness in the for_sig=True case.
Note that this means if someone tries to do a coinjoin with a Trezor One involving non-trivial external inputs,
they will run into the same limit and exception.
- rename globals
- also rm hardcoded strings from qml
- use consistent unit names in qml
(previously mixed sat/vB and sat/byte (latter coming from core lib))
The existing logic of only updating the fee if it is not within 2x of
the current 2-block-eta does not work well for the current mempool.
The current mempool looks a bit weird: you need ~20 sat/vbyte to even get into it,
but there is only around 5 MB of txs paying >25 sat/vbyte.
The estimates look like this:
```
>>> config.fee_estimates
{144: 25764, 25: 27075, 10: 34538, 5: 34538, 2: 34538}
```
This commit changes the logic so that we send update_fee if the old rate is
- below 75% of the current 2-block-eta (instead of 50%), or
- below the 25-block-eta
To reproduce, open two wizards in parallel. Use one to enter the flow and start creating a wallet,
then physically unplug the hw device at the correct time, and use the other wizard to trigger a rescan.
The rescan will unpair the hw device, resulting in device_manager.client_by_id to return None when
continuing the flow on the first wizard.
fixes https://github.com/spesmilo/electrum/issues/8858
fixes https://github.com/spesmilo/electrum/issues/8853
This is a bit ugly, but activeFocus is declared as final and cannot be overridden directly...
```
1.42 | W | gui.qml.qeapp | file:///home/user/wspace/electrum/electrum/gui/qml/components/controls/ElTextArea.qml:23:5: Cannot override FINAL property
```
> These kind of checks look incorrect and confused/confusing for me:
> 43a5d03426/electrum/gui/qml/qeinvoice.py (L388)
> 43a5d03426/electrum/gui/qt/main_window.py (L1801)
> For example, consider creating a local tx that spends all UTXOs in the wallet, and consolidates them to another ismine address.
> Such a tx basically does not change what wallet.get_balance() returns.
> but to the checks listed above, the confirmed balance of the wallet I guess should be 0?
