-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unreliable file systems may lead to wallet file corruption during wallet creation #5082
Comments
If this happened to someone, and they still have the original seed (corresponding to the old existing wallet file), they should restore from that seed and can recover the coins. |
I have found another execution path to trigger that bug, that does not involve an unreliable file system.
This will result in wallet_1 having the new seed and the old addresses |
@ecdsa in your scenario what results in wallet_1 retaining the old addresses? |
Pulled from upstream. Electrum fix for: spesmilo#5082
Pulled from upstream. Electrum fix for: spesmilo#5082
Pulled from upstream. Electrum fix for: spesmilo#5082
@kyuupichan when the user changes the text in the TextEdit, wizard.storage gets set with an instantiated WalletStorage electrum/gui/qt/installwizard.py Line 189 in 624fa47
then the user deletes the actual file on the file system in another process; but the WalletStorage object still exists in memory for the deleted file User will not change the text in the TextEdit anymore. The user clicks next, and the control flow gets here electrum/gui/qt/installwizard.py Lines 296 to 297 in 624fa47
Lines 577 to 582 in 624fa47
At that point, the new wallet creation flow will start, with the existing WalletStorage object still in memory as wizard.storage, containing the "deleted" wallet. |
Deleting a wallet from outside the app while it's running could cause weirdness (see: spesmilo#4984 and spesmilo#5082). Follow ups to fix that.
Deleting a wallet from outside the app while it's running could cause weirdness (see: spesmilo#4984 and spesmilo#5082). Follow ups to fix that.
Deleting a wallet from outside the app while it's running could cause weirdness (see: spesmilo#4984 and spesmilo#5082). Follow ups to fix that.
@ecdsa has been recently looking into #4891, and in more general, ways a user could end up with a corrupted wallet file, where the addresses in the file do not correspond to the xpub.
A potential explanation that might cause this is if os.path.exist "randomly" fails. This is not completely unrealistic if your wallet files are saved on a USB flash drive or a network drive (or similar). Or perhaps on shitty file systems.
os.path.exists
is called multiple times during wallet creation. The idea is that a user can end up with a corrupted wallet if he ends up partially overwriting an existing file.When creating a new wallet, the path would be set to the path of an existing wallet, as due to
os.path.exists
failing, the wizard would think there is no file there yet. However in the wallet storage constructor,os.path.exists
would suddenly work and the existing file would get opened. The wizard would then start modifying the existing file, thinking it's a new one. The wizard would put a new seed and xpub there. Then, the task that creates the addresses for the xpub (create_addresses
) would be a no-op, as it would find that there are already "enough" addresses generated in the file (corresponding to the old wallet!).When the wizard finished, the wallet would then get opened as normally. The wallet file would contain the new seed, new xpub, but old addresses.
Note that while this still can happen on Electrum 3.3.x, it would immediately get recognised, and the user would get several warnings due to the sanity checks added in #4828.
See issues:
#4949 (TARS)
#4891
#5066
#4790
#4462
https://bitcoin.stackexchange.com/questions/78813/same-seed-from-electrum-but-generate-different-bitcoin-addresses
Patch on top of 3.1.3 to trigger the corruption.
The text was updated successfully, but these errors were encountered: