Electrum: Unconfirmed transactions disappearing

[schildbach]

Electrum keeps forgetting unconfirmed low-fee, but wallet-relevant transactions. This has cost me several thousand of Euros, because if Electrum forgets them (and I relied on it) I can't even do CPFP to make them confirm.

I now need to effectively save all incoming transactions to a file because I don't trust Electrum any more in keeping them. On some of those cases I tested for double spends – no one was double-spent by the sender, so they were still perfectly valid.

[AbdussamadA]

It depends on servers for the data relevant to your wallet. Servers drop transactions that pay low fees. You could try switching to a different server until you find one that has your tx in its mempool. Then you can do a cpfp or rbf.

BTW shouldn't you be using your own wallet :)?

[schildbach]

I'm quite surprised that Electrum doesn't do its own persistence. I always thought it only uses the servers for learning about new payments, not for rememering them. I think a wallet should never forgot transactions that are relevant to it. Even if transactions become invalid they should stay (but marked as invalid), so that the user can get notified. Silently deleting transaction is a terrible user experience!

I even lost an outgoing transaction (200 sat/byte CPFP), that doesn't make any sense at all to me as a user.

(I'm always using multiple different wallets in parallel.)

[SomberNight]

I'm quite surprised that Electrum doesn't do its own persistence

Electrum is persisting these transactions, but deletes them if it realizes that the server does not know about them.
https://github.com/spesmilo/electrum/blob/13bf539d175d7d97b9d55453892d380107a4fa8b/lib/wallet.py#L745-L754

[fresheneesz]

I agree with schildbach, Electrum should not delete them, but rather mark them as removed from the mempool, ideally with an easy option for resubmitting manually.

[ecdsa]

I agree that we could keep them in history.
the same feature would be needed to do more than one offline transaction

[barnacs]

I've had a low fee outgoing transaction sitting in the mempool for weeks and it often disappears/reappears when restarting Electrum (depending on which server it connects to, based on the above comments).

Marking transactions that are unknown to the current server in the user interface and adding the option to manually resubmit would be an option but

• marking and unmarking transactions this way between restarts could still be confusing to users without a deep enough understanding of Electrum's architecture
• as a user, I wouldn't know when to resubmit manually because there's still no distinction between a transaction that's missing from the current server and one that's been evicted from the network altogether

Another option would be to keep the tx locally and automatically resubmit when a server doesn't know about it. An option could be introduced to disable the automatic resubmission, letting the tx eventually get evicted from the network. Unconfirmed transactions with auto-resubmit disabled could be marked in the interface but kept in the local history. This would allow users to express the desired eventual state without worrying about the current state of each individual server.

As for incoming transactions, simply keeping them in the local history once seen sounds reasonable to me.

[rikki2018]

II have the same problem with the electrum wallet, was sent me bitcoins 10 January 2017, this amount was divided into several parts ,after 3-4 hours I saw part of the transaction in my wallet electrum , but this was not the full amount ,and they in the unconfirmed status ,and after 2-3 hours when I again opened his wallet electrum ,I found that are no more of these transactions . Now 24 hours passed , and these transactions have not appeared in my wallet . On the blockchain all of the transactions in full size available , but still unconfirmed! You tell me please, what to do ? Please help me ! I've read a lot of forums and a variety of tips , but so far to no avail
P.S. I've using version 3.05 ,updated yesterday , but the problem occurred before the update .

[SomberNight]

This should now be solved on master, due to merging the local_tx branch. The txns that previously disappeared will now be converted to "local transactions" that can e.g. be rebroadcast manually.

[schildbach]

Great, thanks!

[SomberNight]

We've ended up decreasing the scope of the local tx feature for now to transactions that have inputs owned by the wallet. It turned out to be too complex to properly handle the resulting possible conflicts in history for the general case.

For this issue, this means that incoming txns won't be converted to local if they drop out of the mempool (unless they have is_mine inputs...).

Hence, reopening.