It's possible that "another wallet" does not support generating "bc1" addresses and is defaulting to generating the older "legacy" addresses. So, which wallet application did you try and import your private key into?  


What exactly did you do here? I'm confused? You dumped the key from Bitcoin Core and attempted to import it into a different wallet?

According to blockchains support... "error decrypting wallet" means that the password you are using is incorrect.


If you don't have the 12 word backup phrase, then recovery is going to be VERY difficult

You don't need to use -rpcuser and -rpcpassword (and they're being deprecated)... You can simply use the "cookie" method.

When you run bitcoind, you will find a .cookie file is created in your Bitcoin data directory (eg. in your ~\.bitcoin directory) with a randomly generated password. The contents of the .cookie file will look something like this:

Where:
- "__cookie__" is effectively the rpcuser value
and "a14191e6892facf70686a397b126423" is the rpcpassword value

Note: every time bitcoind starts, this file will be regenerated with a new password.


When you run bitcoin-cli it will automatically look for this .cookie in the default location and use the credentials stored in there... if you have set bitcoind to use a "custom" data directory (ie. not ~/.bitcoin), then you can simply invoke bitcoin-cli with the -datadir option so it can still find the .cookie file.

---

EDIT: or just ignore it all like achow101 says and it will just magically work

As far as I'm aware... there is no "replay protection" between BCH and BSV... any transaction made on the BCH network can be freely replayed on the BSV network. The BSV should have been sent to the same address as the BCH, but on the BSV blockchain.

If you sent the BCH to coinex, you should contact them and ask them what happened to your BSV... they've likely received it on the same address that you sent the BCH to. Whether or not they're happy to do "cross-chain" coin recovery is another matter.

No.

Have a read about the "3" type (aka "Pay to Script Hash" aka P2SH) addresses here: https://en.bitcoin.it/wiki/Pay_to_script_hash

- All multisig addresses are P2SH, but not all P2SH addresses are multisig.
- Likewise, all "Nested SegWit" (aka P2SH-P2WPKH) addresses are P2SH, but not all P2SH addresses are Nested SegWit


And as rightly explained by ranochigo... unless you are the "owner" of the address, which access to the private keys and wallet etc... you cannot determine if the address is MultiSig or NestedSegwit or something else until a UTXO has been spent from that address in a transaction and you can see the transaction details and redeem script.

That's possibly one of the old "password recovery phrase" type phrases that blockchain.info used to use.

You can try the old recovery system here: https://login.blockchain.com/wallet/forgot-password?guid=

Before attempting to use pywallet... did you try loading your wallet.dat using the -salvagewallet option in Bitcoin Core?

Again, make sure you have made copies of the original wallet.dat file... and work on a copy of the wallet.dat... not the original file!

If you have a look at mempool stats for the last 2 weeks, we can see that since Jan 8/9, there was a huge uptick in the number of unconfirmed transactions and fee rates being used... with several instances of large fee rate spikes in the last week.

Using "bump fee" will result in Electrum using estimate fee rates based on the network conditions at the time that "bump fee" is used. If you happen to do it when the network is extremely busy, then the fee suggested will be very high.


Unfortunately, it seems that you have learned a somewhat expensive lesson in always double checking the details of the transaction before hitting send

Do you have a rough idea of how many transactions you had in your Armory wallet? It can be a slow process, but it shouldn't take more than an hour or two to scan everything.


Aside from making sure that you have your wallet backup... and then doing a full "Factory Reset" (Help -> Factory Reset -> "Also delete databases and rebuild"), I'm not too sure what else to suggest.

If the Factory Reset doesn't solve it... the only other cause would be corrupt data in actual Bitcoin Core data. That would involve deleting all your Bitcoin Core blocks and resyncing from zero tho...

But it's "OK"... Ledger are now going to delete all our personal data "as fast as possible": https://www.ledger.com/blog/update-efforts-to-protect-your-data-and-prosecute-the-scammers

I assume that includes the data of the extra 20,000 victims of the Shopify leak that have come to light


Ledger Stable|ClosedStableDoor --------------------------> Personal Info Horse

He was talking about old blockchain.info wallets... but according to your first post, you have an Electrum wallet with an Electrum seed...


Are you also trying to recover funds from a blockchain.info wallet that is unrelated to the Electrum wallet?

Are you actually manually running Bitcoin Core and then starting Armory? If so, are you using bitcoind or BitcoinQt (ie. the GUI)?

Or are you just letting Armory launch bitcoind in the background?

Yes... the WIF format key that you should have got from decrypting the .key file (for MultiBit it'll be a "compressed" key so it will start with a "K" or an "L"), contains a checksum...

If you can import that private key into a wallet like Electrum without error, then it's almost guaranteed that the key is not corrupted in any way. Changing even a single character will likely render the entire address invalid.

You can see an example of WIF checksum's in action here: https://gobittest.appspot.com/PrivateKey

Note that this page is quite old so it is using "uncompressed" keys for it's examples, so the WIF keys start with a "5"... it still works with "compressed" keys and WIFs that start with a "K" or "L", it just gives spurious errors.

Very odd... the log files seem to indicate that everything is working "OK"... ArmoryDB is finding the blocks file and appears to be synced up to the latest block... and ArmoryQT seems to be running OK.

What is the colour of the text in the bottom right corner that shows the block number? Is it red, purple or green?

Do you have a bitcoin.conf file in you your D:\bitcoin folder? If so, does it contain the following line? :

Armory believes that your Bitcoin Core "datadir" is: E:\Bitcoin

This folder should have folders labelled "blocks", "chainstate" and "database" (and possibly one or two others)... it should also contain your wallet.dat file.

I'm not sure why you have > 700Gb of blockchain data... is that the size of E:\Bitcoin\Blocks folder? It's possible that you've misconfigured something and it has started downloading to one location, and then you've changed the datadir config and it has downloaded to another location.


Can you please post the contents of your dbLog.txt file.

It doesn't matter how it was broadcast... what matters is the "fee rate" used.

If you have a look here: https://jochen-hoenicke.de/queue/#0,24h
and here: https://mempool.space/

You'll see there are currently something like 130+ blocks of unconfirmed transactions (~100,000 transactions in total)... as such, fee rates being used are quite high... and anything less than 100 sats/vbyte is probably going to take hours if not days to get confirmed.

What is the fee rate that your transaction used?

Yes, post the contents of your debug.log file to pastebin.com, then click the "create new paste" button... it'll generate a unique URL for you which you can copy/paste here.

That way, you won't have issues with the max post length here

Apparently, it was Exodus

Which means that it should be BIP39 and BIP44/BIP84 compatible.... as per the Exodus documentation here: https://support.exodus.io/article/159-import-your-bitcoin-wallet-into-electrum

If the OP is not finding his wallet after following those steps to restore their Exodus wallet in Electrum, then I can only conclude that they have a seed that is "valid" but, is not the seed that generated their Exodus wallet... ie. they have the wrong seed.

Looking back through the release notes... they had installers for Windows, Linux and Mac as far back as 2011:

So, it is indeed possible that you were using Multibit Classic on an old Mac in 2013.

It won't take 223 weeks to sync if that is what you're worried about. It will likely take a few days to catch up, but it would be the best option if you can wait... that way, it'll help prevent a similar problem in the future.


The issue that I can see is that your transaction has not propagated on the network very well. I can't see any transaction with the ID: 020d601b2908df3af33a288f37965a6dceb3542173a11528b6906b1643c0d642 on any of the major block explorers (nor is it in the mempool of my personal bitcoin node).

Either it is invalid, or it's just not being relayed because the fee is too low... currently, the "mempoolminfee" is up over 4 sats/byte: https://statoshi.info/dashboard/db/memory-pool?panelId=3&fullscreen

Any transaction that attempts to pay less than this will likely be dropped from the mempool of most nodes running a "default" config.


No. A "miner" is specialised hardware dedicated to trying to mine Bitcoin blocks. Running a solo mining rig is not going to help you here...