A variant of WaitingDialog that runs the task in the GUI thread,
blocking the GUI. It is probably a code smell to actually use this,
as operations should not block the GUI... still it provides a middle-ground
between blocking the GUI without giving user-feedback and having to refactor
existing code (to avoid blocking).
not sure what it is supposed to catch...
The examples I could come up with would all be actual bugs;
in which case we should let the exception propagate out to the crash reporter.
Scenario: select some UTXOs in the 'Coins' tab. Create a tx and sign it.
Close the tx dialog without broadcasting/etc (cancel tx).
Signatures would remain for selected UTXOs.
Create new tx -> invalid sigs.
- no more passing around "invoice" in GUIs, invoice "paid" detection is now handled by wallet logic
- a tx can now pay for multiple invoices
- an invoice can now be paid by multiple txs (through partial payments)
- new data structure in storage: prevouts_by_scripthash
- type: scripthash -> set of (outpoint, value)
- also, storage upgrade to build this for existing wallets
- persisted states are saved
- state transitions are checked
- transient states are stored in channel.peer_state
- new channel states: 'PREOPENING', 'FUNDED' and 'REDEEMED'
- upgrade storage to version 21
Previously it was impossible to rm the last character in feerate_edit.
e.g. if you held down "backspace", we would keep refilling the field as soon
as it became empty.
scenario: enter extremely high feerate (which we cannot satisfy) then click into fee_edit.
At that moment, fee_edit is empty and both feerate_edit and fee_edit are considered frozen.
As fee_edit has priority, we would construct a tx with default fee.
Now, instead, we won't construct this default fee tx ~as if the click to fee_edit did not happen.
