I have reconsidered and now think that we should always hard-fail
if asserts asserts are disabled. It is just easier to reason about
the code knowing that asserts are evaluated.
If an end-user or library user has a concrete use case where this is
a problem, please open an issue and let us know.
follow-up
0f541be6f10e5464ca13
On mobile, it can take a while before channelDB is loaded. If payment is attempted before the DB
is fully loaded, this would result in a payment failure, but also leaves the payment attempt in IN_PROGRESS
state. This patch adds a more specific ChannelDBNotLoaded exception class, so we can handle this case more
gracefully, since we know the payment didn't succeed.
- case 1: in version 4.4.1, 4.4.2, the qml GUI wizard allowed creating multisig wallets with an old_mpk as cosigner.
- case 2: in version 4.4.0, 4.4.1, 4.4.2, the qml GUI wizard allowed creating multisig wallets with mixed xpub/Ypub/Zpub.
The corresponding missing input validation was a bug in the wizard, it was unintended behaviour. Validation was added in d2cf21fc2b. Note however that there might be users who created such wallet files.
Re case 1 wallet files: there is no version of Electrum that allows spending from such a wallet. Coins received at addresses are not burned, however it is technically challenging to spend them. (unless the multisig can spend without needing the old_mpk cosigner in the quorum).
Re case 2 wallet files: it is possible to create a corresponding spending wallet for such a multisig, however it is a bit tricky. The script type for the addresses in such a heterogeneous xpub wallet is based on the xpub_type of the first keystore. So e.g. given a wallet file [Yprv1, Zpub2] it will have sh(wsh()) scripts, and the cosigner should create a wallet file [Ypub1, Zprv2] (same order).
Technically case 2 wallet files could be "fixed" automatically by converting the xpub types as part of a wallet_db upgrade. However if the wallet files also contain seeds, those cannot be converted ("standard" vs "segwit" electrum seed).
Case 1 wallet files are not possible to "fix" automatically as the cosigner using the old_mpk is not bip32 based.
It is unclear if there are *any* users out there affected by this. I suspect for case 1 it is very likely there are none (not many people have pre-2.0 electrum seeds which were never supported as part of a multisig who would also now try to create a multisig using them); for case 2 however there might be.
This commit breaks both case 1 and case 2 wallets: these wallet files can no longer be opened in new Electrum, an error message is shown and the crash reporter opens. If any potential users opt to send crash reports, at least we will know they exist and can help them recover.
fix signing txs when using old "bitcoin app" (pre-2.1) on the ledger device
```
33.36 | W | transaction | heyheyhey. cp1. include_sigs=True force_legacy=False use_segwit_ser=True
33.36 | W | transaction | heyheyhey. cp2. branch1
33.37 | E | plugins.ledger.ledger |
Traceback (most recent call last):
File "...\electrum\electrum\plugins\ledger\ledger.py", line 669, in sign_transaction
rawTx = tx.serialize_to_network()
File "...\electrum\electrum\transaction.py", line 945, in serialize_to_network
witness = ''.join(self.serialize_witness(x, estimate_size=estimate_size) for x in inputs)
File "...\electrum\electrum\transaction.py", line 945, in <genexpr>
witness = ''.join(self.serialize_witness(x, estimate_size=estimate_size) for x in inputs)
File "...\electrum\electrum\transaction.py", line 839, in serialize_witness
sol = desc.satisfy(allow_dummy=estimate_size, sigdata=txin.part_sigs)
File "...\electrum\electrum\descriptor.py", line 378, in satisfy
sol = self._satisfy_inner(sigdata=sigdata, allow_dummy=allow_dummy)
File "...\electrum\electrum\descriptor.py", line 574, in _satisfy_inner
raise MissingSolutionPiece(f"no sig for {pubkey.hex()}")
electrum.descriptor.MissingSolutionPiece: no sig for 033e92e55923ea25809790f292ee9bd410355ee02492472d9a1ff1b364874d0679
33.38 | I | plugins.ledger.ledger | no sig for 033e92e55923ea25809790f292ee9bd410355ee02492472d9a1ff1b364874d0679
```
fixes https://github.com/spesmilo/electrum/issues/8365
regression from https://github.com/spesmilo/electrum/pull/8230
