Simple test to see if your wallet is suitable for holding coins during a fork:

1. Does your wallet provide you with the private keys for all addresses contained in it?

Yes? Wallet is OK.
No? Wallet is not Ok.

In the case of Mycelium, the answer to 1. is "Yes". So as long as you are happy to store your coins in a mobile wallet on your phone then whatever happens on August 1st, you will be fine... regardless of which way the Mycelium app developers decide to go. You can easily export your Master Private Key/Seed and use the BIP39 mnemonic code converter (https://iancoleman.github.io/bip39/) to get all your private keys and use whatever wallet you need/want.

If you have access to the private keys, you are good to go regardless of what happens. You can put your private key(s) into "LeftForkWallet"™ and have access to "LeftForkCoins"™... and/or you can put your private key(s) into "RightForkWallet"™ and have access to "RightForkCoins"™

What you DO NOT want to do is put your coins in any online service like an exchange/gambling site/web wallet etc where you do not have direct control over the private keys and are at the mercy of that service as to which way they want to send to your coins.

You should also seriously consider implementing a "minimum deposit" system. A lot of the bitcoin casinos do this for exactly the reason that achow101 mentioned earlier:

By implementing a minimum deposit of say 0.001 you can help avoid people filling your deposit wallets with dust inputs and driving up your transaction fees. It will also discourage people trying to use their deposit accounts receiving "cloud mining" payments etc so they can "consolidate" their payments into larger UTXOs at your expense.

Good news: https://blockchain.info/tx/4e9a4b8f3d1990542de83bb44be67c295de516d608576fbd7bb89905715d3b83 is now confirmed!

Bad news: it looks like the trail of unconfirmed transaction continues forward into infinity! Whatever cloud mining service that the "2nd OP" is using, is just creating a massive web/trail of unconfirmed transactions and making it really messy by occasionally paying themselves 0.0004 BTC every 5-10 transactions which they then use as inputs to "giant" consolidation transactions like this one: https://blockchain.info/tx/db559f692810302bad410deeba0557e33b579d6e8b3e00b8bdc8c7c88b4d6b67

Whether that is some sort of attempt to "scam" their users by ensuring the payments never get confirmed, or they're just incompetent I can't really say...

That is what -reindex does... your database got corrupted, so you need to rebuild it. Unfortunately, this means starting right at the beginning and redownloading the entire blockchain again.

Looks like that recovered wallet.dat file is indeed corrupted so that Bitcoin Core is now unable to open it... have you tried with the -salvagewallet option?

If that does not work, then your only other option would be attempting to use pywallet to at least retrieve some private keys from the wallet.dat file. Another user had a similar issue with a corrupted file after recovery here: https://bitcointalk.org/index.php?topic=2012533.0

Seems they are slowly filtering through... I also noticed that it seems to be a big "web" rather than a tree...

A lot of the outputs from the earlier unconfirmed transactions, are actually inputs into that "giant" transaction: https://blockchain.info/tx/449083b66531b4a38188b255ee19c224264ead728467d2da254b8f0ebf453ce8

Quite a mess indeed... but they ARE slowly confirming... I've been rebroadcasting the "first" transaction after a group of unconfirmed transactions get mined... and it seems to rebroadcast the chain up to the max "mempool chain"... and that giant transaction now only has 15 unconfirmed inputs.

All bitcoin addresses are "permanent" addresses. They don't disappear.  Technically, you can send coins to any given bitcoin address an infinite number of times.

So any address you have in your wallet can be used as a permanent receiving address. Most HD wallets like to try to reduce address re-use (to improve privacy and, to a lessor extent, security) by providing a new address each time you receive coins... but this this doesn't stop the old addresses from being able to receive coins... nor should it stop your wallet from being able to access those addresses/coins.

What wallet software are you using?

I tracked it all the way back down about 5 of the chains of unconfirmed transactions from that massive transaction (449083b66531b4a38188b255ee19c224264ead728467d2da254b8f0ebf453ce8) to here: https://blockchain.info/tx/71a3a3a2e9c3d0a8863cf1bb258e8f9233caf5833b38a33d740e52a12f295ed4

They all seem to arrive at this same transaction after some truly ridiculous amount of unconfirmed transactions...

https://blockchain.info/tx/71a3a3a2e9c3d0a8863cf1bb258e8f9233caf5833b38a33d740e52a12f295ed4 did not appear to show on ANY other block explorers other than b.info, so the chances of it being mined were pretty low... so I have rebroadcast via my node and it now seems to be showing on b.info, blocktrail, btc.com and blockcypher.

the raw transaction, should you need it to broadcast it again, is:
I've accelerated it using ViaBTC... and AntPool... so, hopefully, this will confirm soon... the fee isn't "great" but it isn't terrible either considering the current bitcoin network load. Once that one gets confirmed, then if b.info rebroadcasts the other transactions, they should slowly start confirming... otherwise use the "?format=hex" parameter to see the raw hex of all the unconfirmed transactions... and start rebroadcasting them

ie: https://blockchain.info/tx/<TRANSACTIONID>?format=hex

https://blockchain.info/tx/71a3a3a2e9c3d0a8863cf1bb258e8f9233caf5833b38a33d740e52a12f295ed4?format=hex

I doubt you'll find a miner to help... you're looking at easily 50-100 transactions that need to be confirmed before yours is somewhere near the top of the list!

EDIT: I've managed to rebroadcast a few transactions and they're slowly confirming... but it's going to take quite a while to get work through them all given the depth of unconfirmed parents... I suggest you contact the support of your cloud mining service and suggest they learn how "pay-to-many" batch transactions work...

It is simply a case of supply and demand... if the network is busy (lot's of unconfirmed transactions with high fees) you need to pay high fees to get your transaction confirmed quickly. If the network is not busy (less 5K unconfirmed and 99% of transactions paying < 40 sats/byte, like it is right now) you can easily sneak a transaction in and get it confirmed with fees of 50 sats/byte in a few blocks.

I'm guessing that people are out and about doing other things on weekends... family time... relaxing... partying etc and aren't glued to their PCs clogging up the mempool with their trading/gambling/buying/selling etc

As for why some wallets are lower, it really all comes down to how to any given wallet is calculating fees... There is no "set" way for wallets to do this. Each wallet is free to do what they like. So, if it is using a "dynamic" fee system, how exactly they're calculating... is it based on 7 days worth of day? 24 hours worth of data? etc... some wallets don't even use dynamic fees and use fixed values...

Check here: https://blockchain.info/charts/mempool-count to get an idea of how many unconfirmed transactions there are...
then, check here: https://btc.com/stats/unconfirmed-tx to get an idea of the fees that these unconfirmed transactions have.

If you want fast confirmation (ie next block)... aim well above the 1,000,000 byte level If you can wait a while, you can aim lower

Can you also post the db.log file as well? It seems like the recovered wallet.dat is corrupt. The "can't rename" error you see in the debug.log seems to be indicative of an issue during the parsing of the wallet by the DB functions.

I guess the real benefit is the whole "plausible deniability" as mentioned here: https://blog.trezor.io/hide-your-trezor-wallets-with-multiple-passphrases-f2e0834026eb

By putting a small amount of coin in the "default" wallet... ie. the one without any passphrase, a "simple" thief would plug your mnemonic in, see that you have only 0.1 BTC (or whatever you consider to be a small amount of coin) and then probably assume that you only held a small amount of coins and move on to the next target...

Adding on a passphrase (or even two) gives you the option to "hide" extra wallet(s) with your "real" stash of coins... As there is no evidence that you even have a passphrase (it's stored in your head right? and the mnemonic WILL generate a valid decoy wallet that shows some coins/history)... so even a relatively "short" but complex passphrase (10-12 chars with alphanumerics and symbols) should easily give you time to move your coins should you learn that your mnemonic has been compromised... assuming that the thief believes you even have a passphrase setup and are hiding coins.

I guess your best bet is to see if you can find data relating to the "strength" of the "PBKDF2 function" that BIP39 uses... working with the numbers described in the BIP (ie. mnemonic sentence (in UTF-8 NFKD) used as the password, the string 'mnemonic' + passphrase (again in UTF-8 NFKD) used as the salt. The iteration count is set to 2048 and HMAC-SHA512 is used as the pseudo-random function.)

So you used Electrum to create the seed, not some other program?

What was the version of Electrum on your TailsOS that you used to create the seed? Was it a 12 word or 13 word seed?

According to the "how to trade"... Your Marketplace account is tied to your private key... so the only way to get that changed would probably be asking Mycelium support nicely, or generating a new "private key". I'm not entirely sure what private key they're referring to tho... if that is just the private key for a particular address, or the master private key for your HD wallet... I would guess the later.

Pretty sure that if you asked 10 different people what the "recommended" way to achieve this is, you'd probably get 10 different answers... it will come down to a trade off between convenience and perceived level of safety...

You can have a small (short), easy to remember passphrase that makes it fast and convenient, but your level of safety may be less than desired.
You can have a long complex passphrase that makes you feel adequetly secure, but then is way less convenient for you to remember and/or enter when required.

Only you can decide the level of risk you wish to carry...

If you're using Bitpay, you DON'T need 1 confirmation in 15 minutes... you just need to broadcast the transaction within 15 minutes. Once broadcast, they'll happily wait a few hours for the first confirmation... I've done this multiple times with BitPay payments.

If it is for another service/payment processor... tell them their system is dangerously flawed. There is no guarantee in any given 15 minute window that a block will be found. The "10 minute block time" of BTC is an average! I've seen time between blocks of almost an hour before...

If it isn't BitPay, would you mind saying what service it is that has this requirement??

You created a seed using tails?? This is a little bit confusing. Do you mean you used Electrum on TailsOS to create the seed... or you used some other app/utility in TailsOS to create a seed that you are trying to import into Electrum?


so, "next" button stays greyed out when attempting to re-enter seed and you cannot click it right? This indicates that you have entered the seed incorrectly. There are a lot of similar words like kite, kit, kid, kind etc... as already suggested check the wordlist that was linked and see if you can find either a misspelled word, or very similar words to ones you already have... you may have just missed a single letter.

Can you confirm that you have 12 words written down? DO NOT post them here!

So when you create a watching wallet using the address (and one would assume when you check on a block explorer), the BTC are still in that address... that would most likely rule out the possibility of the tails and/or Electrum that you used to create the seed being "fake"... no-one has "stolen" your coins, so that's one less thing to worry about.

if the transaction is only 192 bytes (likely of sending with 1 input and 1 output, sending whole balance so no change) then that fee is 4809 / 192 = 25 sats/byte... most of the current unconfirmed transactions are in the sub-20 sats/byte bracket... according to: https://btc.com/stats/unconfirmed-tx

I'd guess that fee stands a relatively decent chance of confirming in a few hours...

As no one seems to have addressed this concern as yet... private keys are really just very large numbers. They are NOT wallet specific. A private key generated by WalletA should be able to be used by Wallets B through Z (assuming of course that these wallets allow importing of private keys).

There are also several open source and freely available services (like bitaddress.org) that will "convert" private keys in multiple formats to (WIF, WIFC, HEX, B64, B6, MINI, BIP38) and output WIF, WIF Compressed, Hex and Base64 representations of these private keys... They provide full sources and are able to be downloaded and run on airgapped/offline machines etc.

The maths and algorithms behind all of the address conversions etc are also widely known and published.

In the specific case of Electrum, which uses a "proprietary" mnemonic to seed calculation method (ie. Not BIP39)... if you're super paranoid that the software may die and/or stop being updated... you can also simply store a copy of the source code or application on your secure pendrive along with your seed/keys...

or alternatively use the getmasterprivate() command on the Electrum console to get the BIP32 Root Key aka "xprv" (that can be plugged into an offline copy of https://iancoleman.github.io/bip39/):



and used with a BIP32 derivation path of m/0 and m/1 to get your "receive" and "change" address/keys respectively.

I take it that this means that Bitcoin Core was unable to read the recovered wallet.dat file that you attempted to import?  Did you get any errors... or did it just come up with a zero balance? If it came up with a zero balance, it is highly likely that this was just an empty wallet that had been generated by an earlier installation of Bitcoin Core but was never used.

If you got errors, can you post the debug.log from when you attempted to load the recovered wallet.dat. NOTE: Please use pastebin.com for this and just post the pastebin link!

I'm sure there are... but to be honest, I don't know exactly what they are... The attacker would need a fully indexed copy of the blockchain... and would need to generate at least 20-50 addresses AND change addresses PER generated seed and scan the blockchain for each of those addresses... or have generated a DB with appropriate indexes referencing every address seen on the blockchain.

Given that this involves a lot of SHA256() stuff (to get from private key to public key to address), the time taken doing hundreds and thousands of these calculations isn't exactly trivial... but then you have ASICs and GPUs that are measuring in GH/s etc when doing essentially the same thing when mining...

Personally, I suspect the address balance lookup is probably the real time limiting factor in all this... as it isn't just pure number crunching like the address generation... but honestly, I have no hard data to back this up.