Generally, most of the payment processors, they only care that a valid transaction was broadcast to the network within the timeframe that they show the invoice as being "valid"... They will generally just not process your order or credit your account until that transaction is actually confirmed.

Any service that issues an invoice for say "30 minutes" and expects that a user can guarantee confirmation in that time frame (regardless of fee paid) is asking for trouble. As you saw, there can indeed be time periods where a block is not found for over an hour!

Sometimes, miners are just "unlucky"

Not aware of any wordlists using the word "overweight", it's not even a valid word for the old legacy blockchain.info password recovery... unless your relative was trying to be clever and obfuscate their seed by using "overweight" instead of "fat"?

Is the seed mnemonic 12 or 24 words long? and how many "non-BIP39" words are there exactly?

Your question isn't very clear. Do you mean they are spending the same UTXO with the 100 sat/byte fees as your 1 sat/byte transaction? That is to say, are they all trying to spend the "same" 1btc? Or are they all spending different coins?

Basically, I'm not sure if you're trying to understand how double-spends work, or how miners prioritise transactions to be included in a block?

Was your wallet.dat encrypted? Did it have a password? If it did, then this method of scanning for hex bytes "0201010420" and then taking the next 32 bytes will not work.

That method only works if the keys in the wallet.dat are not encrypted with a password.

Did you actually specify the correct values for those options? You need to specify the size of the device, what the device actually is, and where to put the output.

for example, if you were scanning a 8gig thumbdrive that was connected as F:, and you wanted to put the recovered files in C:\temp, you would use something like:


While it is true that PyWallet has not been updated in years, so it doesn't always play nicely with "new" versions of wallet.dat, it is still fairly useful. Unfortuantely, it to is somewhat limited with regards to what it can do if the wallet.dat file is really corrupted. Given that you're unable to load it into Bitcoin Core, it would appear that the wallet.dat is quite corrupted. Still, it could be worth a try.


Honestly, you'd need to copy/paste the actual contents of the debug.log file for people to be able to diagnose it properly. Giving us little snippets of the debug output does not help much The debug.log file is probably quite large, so my advice would be to shutdown Bitcoin Core, delete the debug.log file, try and restart Bitcoin Core.

After it has failed and shutdown again, then open debug.log again and copy/paste the entire contents of debug.log to https://pastebin.com/ and click the "create new paste" button. It will generate a unique URL for you. Finally, copy/paste that unique URL here.

NOTE: debug.log does not contain any "secrets", so you don't need to worry about anyone being able to steal your coins or anything, but it may reduce your privacy by showing IP addresses etc.

Try and manually select a different server from the list displayed in "Tools -> Network"... You need to "right click" one of the servers in the list and select the "Use as server" option:



Note that you might need to try a few before it works.

Yes, if you selected the "Encrypt Wallet File" option when creating the wallet, then your wallet file will show as "a mess of unformatted characters":



If your wallet files is currently encrypted, but you're wanting to view it in the text editor, you would need to select the menu options "Wallet -> Password". You'll see a note telling you, that your wallet is both password protected and encrypted.

You can simply re-enter your password into all 3 boxes and then untick the "Encrypt wallet file" option:



You should then be able to open the wallet file in a text editor and see the JSON layout. Note that with "password protection", all the "important" stuff (like seeds, private keys etc) will still be stored as encrypted text within the JSON. If you want to see the plaintext for seeds/private keys, you need to set a blank password as well.

I'm fairly sure it gets flagged for attempting to connect to certain IPs/Domains that the antivirus vendor has flagged as being involved with "Coinminers" etc... This is why UserA of <AntivirusApp> might see the warning, and UserB does not. Essentially, UserA's copy of Electrum tries to connect to the Electrum server hosted at <FlaggedIP/Domain>, while UserB's copy of Electrum is connecting to different servers/nodes.

That's only really relevant to the Nano S... the Nano X has more storage, so you don't need to worry so much about having to uninstall/install apps if you use a lot of different coins. If you only use one or two different coins, then even the Nano S is perfectly fine.

Upgrading firmware on both the Nano S and Nano X is relatively painless. There were some issues previously, on the Nano S, that were caused because people had not updated their devices for a while and the latest firmware was not compatible with their old bootloader. As far as I'm aware, there hasn't been any similar issue in over 2 years. These days it's more just "delays" caused by Ledger's "rolling update" policy as the servers take a bit of a pounding when new updates are released due to the number of devices in circulation.


There is an "unfixable" flaw with the device, that allows anyone with physical access to the device to extract the 24 word seed mnemonic. The only mitigation to this flaw, is by using the BIP39 passphrase functionality, as that is not stored on the device but used at "runtime" in combination with the 24 word seed mnemonic to derive your actual wallet seed... Trezor recommend users use long and complex passphrases to prevent loss, should your device be stolen etc.


Honestly? Either one will be just fine for your situation... Both Ledger and Trezor support Monero (XMR), as well as BTC obviously. I own both a Nano S and a Trezor ONE. They both have pros/cons. I would like a Nano X/Trezor T, but don't really see the need to upgrade as the extra features offered by the X and T just aren't worth the cost for me personally.

They're both capable devices, compatible with a number of popular wallets (like Mycelium for mobile use and Electrum for desktop use etc) if you don't like Ledger Live or the Trezor web wallet and both support quite a variety of cryptocurrencies.

"salvagewallet" failed then... It would appear that the wallet file is too corrupted for Bitcoin Core to be able to recover it. You will need to try an alternative method of extracting the private keys from the wallet.dat.

Unfortunately, most of the mthods available require the knowledge and use of command line tools and Python scripts like "PyWallet". These are not "start a program, click a button"-type solutions. Additionally, there is no guarantee that they'll be able to recover anything depending on how corrupted the wallet.dat is.

How much experience do you have with the commandline and Python scripts?

You'll need to have a look in the debug.log file in the Bitcoin Core "Datadir" and see what error is being logged when it shuts down... without knowing that error, no one will be able to tell you why it is doing what it is doing, nor how to fix it.

Unless you have a fully synced copy of it already available on a another trusted machine, the "fastest" way to sync it is to just let Bitcoin Core sync "naturally"... There are other tips, like use an SSD to store the blockchain/chainstate data, if you have a lot of RAM set the "dbcache" value to at least half your total RAM size etc.

Yes, it takes hours/days, but there really isn't any way to avoid it.

Yes, this means you exported private keys from your previous wallet... and imported them into Electrum. There is no seed in such a case... only private keys stored in the Electrum wallet file. As per my previous message, you should be able to use "Wallet -> Private Keys -> Export" to retrieve these private keys, and then simply import them into ElectrumSV.


It's possible that ElectrumSV is attempting to re-open the wallet file that it can't read (due to wallet file format updates that aren't in ElectrumSV) and is crashing.

I would suggest that you try and remove the config file from the "C:\Users\YOURUSERNAME\AppData\Roaming\ElectrumSV" folder, then try restarting ElectrumSV. That should "factory reset" ElectrumSV so it doesn't try to open the old wallet file and it should start up normally.

Then you can create a new wallet file, and import your private keys from Electrum.

I am not familiar with this "Desktop Configuration File" that you are referring to... what Linux Distro/version are you running?

"Swiping across"? You mean on the button bar? As far as I'm aware, that basically just allows you to switch from one app to another in your "Recent Items" history, it doesn't close anything down. Traditional Android UX was to use the back button to "exit" an app, but it's changed a number of times over the various iterations of Android.

What I do know is that Electrum doesn't have an "exit" menu item, instead you press back button once (when NOT in a "submenu"), and you'll get the "(!) Press again to exit" prompt shown on the screen. Pressing "back" again a 2nd time then shuts the app down.

That's not unexpected. Mycelium allows you to use/manage all three of the common address types in the one wallet... so you can see/use "1"-type (P2PKH), "3"-type (P2SH-Segwit) and "bc1"-type (P2WPKH, "native segwit") addresses and their balances all at the same time.

Unfortunately, Electrum only allows one address type per wallet. The transaction you sent for the ~$150, sent the change to a "3"-type address. So, Electrum would not be able to see/display that address with it's coins.

If you restore your seed words on Electrum, but this time, select the "P2SH-SegWit (p2wpkh-p2sh)" option, you should then see the transactions/amount that is missing from the "Legacy (p2pkh)" Electrum wallet that you would have already restored:



NOTE: It might also be worth, creating a 3rd wallet, using your Mycelium seed words and selecting the "Native Segwit (p2wpkh)" option, and see if that also shows any transaction history.

dumpprivkey is a very "slow" way to export multiple private keys... If you have a large number of private keys to export, using dumpwallet is a faster option

The full command is:

For example, on Windows... to output to a file called "Keys.txt" on your D: drive in a folder called "walletdump", you would use:

It can take a number of seconds/minutes to return a response to scantxoutset...

To see the percentage progress of the "current" scan, you can use the following command from another shell:

For example, the output:
shows us that the scan is 13% complete.

That's not possible. Electrum does not read multibit wallet files. So, you either used a MultiBit HD seed, or you must have exported your private keys from multibit, then imported those private keys into Electrum. Does your Electrum wallet say "[Standard]" or "[Imported]" at the top?


In any case, regardless of whether you used a BIP39 seed or imported private keys, you should still be able to see your private keys within Electrum... simply use the "Wallet -> Private Keys -> Export" option:


That will export all the generated private keys...


if you just want the private key for a specific address, you can goto the "Addresses" tab (you might need to use "View -> Show Addresses" first), then right click on an address, and select "private key":

The article mentions downloading the wallet backup file, but not how they did this...

I'd be interested to know how they went about actually getting hold of the wallet.aes.json wallet backup file, as the old methods don't seem like they work anymore. So, unless you happen to already have the file included in an old email, it would seem that you're out of luck.