No... you're using sudo... so the root account can write to the disk. I suspect that you're not running bitcoind as root (and you shouldn't be!) which is why it errors out saying that it can't write the temp file.


It would appear that it is indeed most likely a permissions issue... but I'm surprised that a sudo chown and sudo chgrp won't let you modify the permissions tho?

Yes... that should indeed work as you intend. When the app starts up (assuming you don't use any commandline parameters), it will default to looking in the ~/.bitcoin folder for a bitcoin.conf... if you then specify in that bitcoin.conf that the "datadir" is somewhere else... then the application will use that other datadir for the location of the blocks and wallets etc.

Normally that would work... but given that the application is advising that transaction data may be incorrect, listaddressgroupings output may also be inaccurate (as it is effectively showing what the wallet "believes" based on transaction data it holds).

To be 100% sure of the wallet balance... it seems the OP will need to scan every address/private key


Another option... might be to try the "bitcoin-wallet" binary and the salvage option (as always, work with a copy of the wallet.dat) and see if that helps remove the error.

Note that it may be necessary to use rescanblockchain command with Bitcoin Core, after trying the salvage option, to ensure that Bitcoin Core has properly rescanned the blockchain data for appropriate transactions.

---

Another thought is that it's possible that the wallet.dat is actually for an altcoin... and not Bitcoin. OP should check some of the listed transactions shown in the wallet to confirm that they are viewable on a Block Explorer.

Right click a transaction on the "transactions" tab, and copy the Transaction ID... then paste it into the search on a blockchair.com. If it's not shown on the Bitcoin blockchain it might show up on an altcoin chain like Litecoin or Dogecoin.

Huh... I wonder why my system keeps complaining about Electrum? It is basically the same... genuine Windows 10 with Windows Defender etc... Although, now that I think about it, I haven't downloaded Electrum in a while (missed a couple of versions), so maybe the Windows system is working now. Who knows? maybe all the "report safe" things I clicked actually worked!

It's also possible that it was the browser (Edge) being stupid? But I'm almost certain it was Windows system dialogs that were popping up saying that it had been blocked.

"Abandon Tx" is probably the best way forward. Dogecoin Core probably also still supports the -zapwallettxes command line option (which has been removed from Bitcoin Core).

If you use that, it'll completely wipe all the transaction data from your wallet (so you don't end up with the abandoned transaction with a big X next to it in your transaction history)... you can then use rescan and it should then find all the actual transaction data (as per the block chain data) and you'll be able to see your correct balances etc

Pywallet will (should) find all your private keys but will only output showing them as P2PKH (aka "Legacy") addresses... whereas Bitcoin Core supports using P2PKH, P2SH-P2WPKH (aka "Nested Segwit") and P2WPKH (aka "Native Segwit") addresses from your private keys.

Chances are that the list of private keys will be the same between the pywallet output and the Bitcoin Core dump... it'll just be the list of addresses which is different.

I would suggest looking at the sets of WIF keys displayed from each and checking that they are the "same". Note that they may not be output in the same order... I know that the dumpwallet in Bitcoin Core doesn't usually output them in derivation path sequence order... not sure about Pywallet.

You can't just import a wallet dump directly into Electrum. The wallet dump will not be in an Electrum wallet file format... which is the reason why you get the error.

You need to take the private keys from the wallet dump and import them manually into Electrum. Note that this means you are likely to have to import over 1000 keys, as you've no idea exactly which addresses, if any, actually have coins on them.


Is your Bitcoin Core setup in "pruned" mode? Check the "Settings -> Options -> Main" menu and make sure the "Prune block storage" option is disabled. Once you are sure it is disabled, and your Bitcoin Core is fully synced, then maybe try using rescanblockchain in "Window -> Console"... that should force the wallet to rescan all the block data which should make sure that your transaction history and wallet balances are correct.


You might also want to work with a copy of your wallet.dat.

You can't... if you don't have a copy of the original wallet.dat, your chances of retrieving your coins are zero.

Do you have any sort of backup of the original wallet.dat? If not, then as nc50lc says, you'll need to try some sort of file recovery software to see if you can recover a previous version of the wallet file.

are you trying to run pywallet on (a copy of) the original wallet.dat or a copy of the wallet.dat after you tried bitcoin-wallet.exe and salvage?

It looks like the file might be quite badly corrupted if it's unable to parse the data correctly

Yeah, it looks like some preconfigured system that is setup using absolute fees as opposed to calculating fee rates. Not sure why you would do that, but there you go... As someone mentioned above, when you're transacting millions, nickel and diming on fees isn't really a concern. What's $150-200 when you're shifting $5mil worth of coins?

Aside from these cases of absolute fees being used by what appears to be commercial entities... another common scenario I have noted for ridiculously high fees, is malware/theft. The thieves tend to send with very high fees to (I assume) try and prevent any chance of a double spend and, of course, guarantee next block inclusion of their transaction.

ranchigo missed one important step...

When you use the "I already have a seed" option and put your 2FA 12 word seed in... you will be asked if you want to "Keep" or "Disable" 2FA... you must select the "disable" option!



That will ensure that the wallet created has the minimum number of master private keys to be able to sign transactions.

The rest of what he said is important tho... you should move your funds away from the recovered 2fa wallet.

Oh ok... you're using the "new" version of Pywallet... I have a feeling that the latest version might actually require Python 3 and not Python 2.

In any case... try:



Opening in notepad is guaranteed to show all sorts of weird characters and symbols, because notepad is for text based files... and a wallet.dat is a binary database file. So, it isn't necessarily encrypted... but chances are pretty good that it is.

However, if the file is indeed encrypted and you don't have the passphrase, you're not going to be able to recover the private keys. It's as simple as that. You can try running without the --passphrase option and see if you get the "Sec" fields that show the private keys...


If you only get addresses/public keys... and you don't see any "sec" fields with WIF private keys and hex private keys, then the file is encrypted.

This is indeed the issue. Something is preventing Armory from fully syncing. Possible issues are:

1. Bitcoin Core is not fully synced. Check in Bitcoin Core: "Window -> Information" and see what the block height is shown as. If it is 496893, then Bitcoin Core has not properly synced. Check the debug.log file in Bitcoin Core datadir for errors.

2. If Bitcoin Core is synced ok (it is showing as 688991+) then the problem is somewhere in the Armory system. You'll need to post your armorylog.txt and dblog.txt files (use https://pastebin.com/) so we can see what the errors are.

That's correct... they are a completely different instruction set. However, the M1 Apples have a "Rosetta Translation" system that can run some x86_64 code: https://developer.apple.com/documentation/apple-silicon/about-the-rosetta-translation-environment

So, Armory might still work on the M1-based laptops... but given that Armory and MacOSX were already somewhat problematic, you might be better using a virtual machine (running Linux or Windows)... or waiting until an M1 native build is released.

Of course... I was just trying to show an additional benefit to complement the rather exhaustive list that you had already shown.

Granted, they're not necessarily for "everyone"... but I still think they're a good idea and that the benefits outweigh and additional "complexity"

To fix the ecdsa error, you just need to install the ecdsa Python module using pip:

Although, it's not actually required.


The commandline you're using is wrong.

everything after the > won't be available to pywallet... so, the --passphrase parameter is in the wrong place... also the > command tells the OS where to redirect the output of the script... so instead of displaying it to the screen, it is attempting to write it to a file called "wallet.text --passphrase= PASSPHRASE"

So, try something like this:

This assumes that the wallet.dat you're trying to dump info from is in the same folder that pywallet.py is in... and it is called "wallet.dat". Where exactly is your corrupt wallet.dat located and what is the filename?


It's not... as it says, it just might slow down the decryption, but you're talking seconds rather than minutes or hours etc.

I would tend to agree... unfortunately, none of us except the OP were there... and know exactly what has transpired. To a certain extent we have to take the OP's word for what they did and what information they have... and that the information they are providing is true and correct.

However, a set of 12 seed words doesn't magically start producing different wallet addresses.

So, it's either the correct seed and some other variable like the seed extenstion phrase or derivation path has changed, or "BIP39 seed" option was selected, or it's some weird bug... or the seed is just wrong.

¯\_(ツ)_/¯

I wish the OP the best of luck, but there really isn't anything "new" to suggest at this point...

As far as I'm aware, Electrum.org was never an issue. It was certain domains/IPs that were hosting Electrum servers. They had been blacklisted by a couple of the more "helpful" Antivirus applications that try to prevent connections to domains/IPs known for distributing malware, being botnet controllers, being malware cryptominer controllers etc.

In any case, given that the portable worked, and the installed .exe didn't... Either the portable was connecting to different servers or it was some weird Windows firewall thing blocking the connections then. Then isn't really anything different between the installed/portable versions from a networking perspective... and Windows can be a bit problematic like that sometimes. Especially, if you click the wrong button when it first prompts to allow/block connections for the .exe on public/private networks etc.

Sorry... on reflection "device specific" was a bad choice of words... I should have said "wallet specific" or "vendor specific".

That is to say... is that a Ledger specific derivation path, or is it a Tron "default" derivation path

I'm wondering if this is at all related to issues from several years ago where some Electrum servers were linked to IPs/domains that had been blocked for "malware mining" etc?

Additionally, I know that Windows Defender complains a lot about Electrum. I am always getting "Windows has blocked this file"-type errors when trying to download/install Electrum.

I click "keep", "report as safe" etc... and every new version, the same thing seems to happen I know it's due to PyInstaller being marked "bad" and not limited to just Electrum, but honestly, the heuristics are just stupid