Well, given the recovered files were corrupted... then I guess the OP got unlucky. 

Something was obviously written to disk over the old (deleted) wallet.dat data... regardless of whether or not it was the Service Pack... the point was that the computer was obviously being used and data was being written to disk. That increases the risk of data corruption.

Like I said, there is a chance that they might be able to find an intact key by doing a raw byte search on the disk... but I wouldn't be terribly confident of a successful outcome. No harm in trying. As Jet Cash said tho... make an image of the drive first and search the image.

The instructions in build-windows.md seem to work OK... I didn't need to do any "scouring" it was basically as simple as setup WSL, install Ubuntu 18.04 in WSL, copy/paste the commands from the readme to the terminal.

Additionally, there are notes on how to build using Visual Studio here: https://github.com/bitcoin/bitcoin/blob/master/build_msvc/README.md

I just didn't do it that way because I don't have VS installed

As mentioned earlier... use the command that has the --datadir=. option in it if you get "no such file or directory __db.001"

May I ask what you think would actually be achieved by doing this?

Are you thinking that by having multiple blockchains, we're going to have multiple blocks being solved on multiple chains and therefore be able to have more transactions? If so, your reasoning is flawed... as how do you deal with "intergroup" transactions? You're going to be doubling up transactions... ie. PersonA-Group1 -> PersonB-Group2... you somehow need a transaction on Group1 blockchain AND on Group2 blockchain. What happens if a Group does rouge? What happens to all the users in that group? Can users choose which group they want to be in?

How do you deal with HD wallets and address creation to ensure that GroupX wallet private keys/addresses are only used on GroupX blockchain? Are you going to only use miner issued private keys/addresses?

Additionally, you make it impossible for users to actually see for themselves the data from the other blockchains... they have no way of knowing if something is accurate with trusting their particular group of miners etc.


Honestly, this sounds like a terrible idea. All the downsides of centralisation, with none of the benefits of Bitcoin

where is your pywallet.py file? Does the folder "C:\Users\Catherine\Downloads\pywallet\" exist?

If it does exist, does your command prompt say:

This is likely your bottleneck... is that an HDD or an SSD of some description? If it is an HDD, that is definitely your bottleneck... the initial block download involves a LOT of disk I/O... unless you use a sizeable dbcache value, then your storage device will be working overtime... and HDD's are sloooooooooooow when compared to SSD storage.

No. Unless you are using the "onlynet=onion" option which makes all outbound connections via Tor... but that still doesn't affect inbound connections.

So, the nodes should still be able to sync quite happily over ipv4 (and ipv6) connections... regardless of whether or not the node has been able to bind to 18334 for tor. If you're not interesting in tor, just ignore the error.

The easiest way is to just leave off the --passphrase option... if you don't include it, and the wallet.dat has a passphrase, it won't be able to show the private keys

For instance:


Also, if you get a "No such file or directory" error about there not being a __db.001 file... you will need a --datadir, so the command would be:

Once you're ready to output with the private keys displayed, just remember to add the --passphrase option back

It has nothing to do with any encryption. The encryption of the wallet file has not changed... it is simply the "seed_version" value being stored in the wallet file...

Electrum uses the "seed_version" value as a "wallet version" value and it is incremented whenever modifications are made that alters the wallet file format in some manner. This is to prevent new additions and/or modifications to the wallet file structure causing unexpected errors should an "upgraded" wallet be attempted to be opened in an older version of Electrum that is not expecting them.

So, when wallet file format changes are made, the "version" is incremented... and the wallet is upgraded the first time the wallet file is opened using a newer version. At some point between 4.0.5 and 4.0.9, the version was incremented from 32 to 33... hence why, after opening the wallet file with 4.0.9, the wallet file can no longer be opened in 4.0.5.

In the future, should you wish to maintain the ability to "rollback" to the previous version in case an update causes issues... you should backup your wallet file before you update Electrum. This will mean you have a copy of the wallet file with the "earlier" version.


NOTE: not all updates actually modify the version... the wallet version was actually last updated in version 4.0.8...

Oh... silly me! I forgot to include the "Python.exe" part of the commands! 

NOTE: You need to be in the directory where "pywallet.py" is located for those commands to run properly... given the previous history... after opening "cmd", you should use the following command first:

Then you can try the following:

To dump out the wallet INCLUDING your private keys to the screen ONLY:

To dump out the wallet INCLUDING your private keys to a text file:

This is assuming that the recovered_wallet_1511377727.dat still exists... and you remember what the passphrase was when you created it when doing the pywallet recovery.

Then it probably isn't an issue... the 2nd instance cannot bind to that port as obviously it is already in used by the 1st instance of Bitcoin Core...

It shouldn't be preventing the 2 instances from talking to other nodes (or each other), so you can just ignore the error.

What happens if you lookup the "1xxxxx" address that is on the paper wallet using one or more of the following block explorers?

https://www.blockchair.com/
https://www.blockstream.info/
https://www.blockchain.com/
https://www.btc.com/
https://live.blockcypher.com/btc/

Do you see some transaction history? Does it indicate that there is a positive "final balance" or does it show as zero? The transaction history is often the important clue (even with a zero balance), as it means that the address was in fact "used" at some point...

If you have transaction history, but zero balance, it means the coins were spent at some point.
If you have no transaction history, it means the paper wallet was never funded and can be "ignored".


You also really need to check which version of MultiBit you were using... was it MultiBit Classic:



or was it MultiBit HD:



The method to recover coins from each is slightly different.

Honestly... that sounds like a terrible idea and something that could be exploited to hack your wallet and steal your funds if the device was stolen... or someone decided that a $5 wrench might help persuade you to unlock your wallet.

The idea of the "kill switch" (ie. wipe the device) after exceeding the PIN/Password limit is to prevent someone attempting to bruteforce a device that they have "found" (stolen) by endlessly trying difference PINs/Passwords. Additionally, if the device isn't wiped, you leave yourself open to the possibility of data extraction (similar to the Trezor memory exploit)... even if the number of tries has been exceeded.

The "manual override" already exists... it's your 12/24 word recovery phrase! If you exceed the PIN/Password limit... you simply restore from your recovery phrase and away you go.

Just as an update to this... https://github.com/spesmilo/electrum/pull/6968 has been merged into "master"... so soon you will be able to see miner's fees in fiat on the appropriate dialogs

Thanks to the "real" Electrum dev's for their review and patience.

Can I ask why you need/want to be able to import modules on the Electrum console? It's really not the place to be writing raw python code!

If you need to be creating a Python script, go ahead and create a Python script and then run it using Python...

You did miss it...


Clicking that link will take you here: https://download.electrum.org/

It has every version released since version 1.8!

However, I would strongly recommend you don't blindly download old versions unless you are 100% sure of what you're doing... and you have a very good reason for rolling back to a previous version.

Honestly, it sounds like you have 8 inputs and would be creating a fairly "large" transaction from a "data size" point of view. Given how ridiculously busy the network is, and how high fees are currently, it wouldn't surprise me that the default fee estimation in Electrum is struggling with calculating a decent fee.  There are countless users on these forums at the moment with "stuck transactions"... there are over 100k unconfirmed transactions at the moment

Look at https://mempool.space/ and https://jochen-hoenicke.de/queue/#BTC,24h and https://bitcoiner.live/?confidence=0.9 to get a feel for the best rates to use for fees and choose one appropriate to your requirements (ie. higher for more chance of getting fast confirmation... lower if you don't care about confirmation time and want to send cheaply)

Again... it's NOT BTH... it's BCH... (or ETH, but there is no way ETH would show up in Electron Cash)... Please make sure that you're using the correct abbreviations to avoid confusion.

As for how to get from BCH to BTC... you'll need to send your BCH to an Exchange (Poloniex, BitMex, Binance etc)... and convert it to BTC and then send the coins to wherever you need. BUT... I would advise that you triple check the fees involved when using exchanges... a lot of them have fixed withdrawal fees which are simply ridiculous with today's value of BTC... (ie. 0.00050000 BTC withdrawal fees that's ~US$25!!?! )

Other options are the "instaswap" services like changelly and shapeshift etc... again, be wary of fees.

Electrum is a BTC only wallet... so it can only show BTC.

Also... the BIP's are "Bitcoin Improvement Proposals"... ergo BIP32, BIP39 and BIP44 are all actually Bitcoin orientated... that fact that some Altcoin's choose to implement/mimic similar functionality does not mean that a "BIPxx compatible" wallet is "multicurrency".

If you need to be able to see Altcoin activity, you'll either need to track down the forked versions of Electrum that a lot of Altcoin devs/projects created specificially for their project... or use a "multicoin" wallet like Coinomi...

Can you post the armorylog.txt logfile?

Also, what OS are you using... and what are the exact versions of Armory and Bitcoin Core you are you using? I would recommend:

Bitcoin Core: 0.21.0
Armory: 0.96.5 (get this from here: https://btcarmory.com/ (DO NOT USE bitcoinarmory.com... it's old and outdated!)

The fact that it goes a bit haywire when you're trying to restore the wallet indicates that there might be something unusual about one of the transactions involving your wallet that is causing Armory issues... not sure how you'd go about debugging that though, as nothing obvious showing up in the debug logs.

Possibly caused by corrupt data in your Bitcoin Core block data... maybe try shutting down Armory and Bitcoin Core... and restarting Bitcoin Core using the -reindex option. That should force it to recheck it's data and redownload anything that has been corrupted.

After the reindex is complete... start Armory, "Rebuild and Rescan Databases" and then restart Armory.