- 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
When "importing" a psbt, we accept witness utxos even for legacy inputs
(warning shown to user in gui).
When "exporting" a psbt, we follow the spec; except when exporting as a QR code,
in which case we include witness utxos for all inputs.
This makes QR codes for psbts with legacy inputs feasible, just like they
were before, with our custom tx serialization format (with the same risk,
of burning coins as miner fees).
when pasting a new invoice and paying it
Traceback (most recent call last):
File "/home/user/wspace/electrum/electrum/gui/kivy/uix/screens.py", line 358, in _do_send_onchain
tx = self.app.wallet.make_unsigned_transaction(coins, outputs, None)
File "/home/user/wspace/electrum/electrum/wallet.py", line 849, in make_unsigned_transaction
if o.type == TYPE_ADDRESS:
AttributeError: 'tuple' object has no attribute 'type'
when loading back a saved invoice
Traceback (most recent call last):
File "/home/user/wspace/electrum/electrum/gui/kivy/uix/screens.py", line 358, in _do_send_onchain
tx = self.app.wallet.make_unsigned_transaction(coins, outputs, None)
File "/home/user/wspace/electrum/electrum/wallet.py", line 849, in make_unsigned_transaction
if o.type == TYPE_ADDRESS:
AttributeError: 'list' object has no attribute 'type'
- Terminology: use 'invoices' for outgoing payments, 'requests' for incoming payments
- At the GUI level, try to handle invoices in a generic way.
- Display ongoing payments in send tab.
- create unique instances of channels_dialog and addresses_dialog
- display and refresh balances in channels_dialog
- improve formatting of tx history
- repurpose left button in receive_tab
There are now two internal strategies to bump the fee of a txn.
bump fee method 1: keep all inputs, keep all not is_mine outputs,
allow adding new inputs
bump fee method 2: keep all inputs, no new inputs are added,
allow decreasing and removing outputs (change is decreased first)
Method 2 is less "safe" as it might end up decreasing e.g. a payment to a merchant;
but e.g. if the user has sent "Max" previously, this is the only way to RBF.
We try method 1 first, and fail-over to method 2.
Previous versions always used method 2.
fixes#3652
