If you are still having issues with your MultiBit Classic... Try this: https://github.com/HardCorePawn/multibit_recovery

I wrote a couple of small python scripts (based on decrypt_bitcoinj_seed by gurnec, the btcrecover guy ) to try and help recover funds from "broken" MultiBit HD and MultiBit classic wallets... If I get some time, I'll write up a guide (with pretty pictures)...

MultiBit Classic is easy, it just decrypts your key-backup file using your wallet password... and dumps out the privatekeys... you can then import them all into another wallet.  
EDIT: There is also a script that works on wallet files now if you don't have a key-backup

MultiBitHD is a P.I.T.A    

You gotta use the BIP39 tool to find all the addresses/private keys for your Seed and hunt through them looking for the ones that still have coins... my script tries to hunt through your mbhd.wallet.aes file looking for unspent transactions to try and narrow down the search....

You can donate here if these scripts help you recover your funds: 1NyVDDmhZPcyKhyrkiUFZbqPPuiYxwTujb

As explained, you seem to have a lot of transactions into your wallet with very small amounts of bitcoin. When you go to send ALL of your bitcoins, you then need to include ALL of these inputs. Each input to a bitcoin transaction will use up around 148... each output is around 34 bytes... and there are some fixed bytes (around 10 bytes) per transaction.

So if you have 1 input and 1 output... your transaction will only be around 192 bytes... (148 + 34 + 10 = 192). Fees are calculated on a "per byte" basis... so if the wallet is setting a fee of say 100 sats/byte... you have 192 bytes... your fee will be 19200 sats (192 * 100).

However, in your case, you had TWELVE inputs... (12*148 = 1776 bytes  )... and 2 outputs (2*34 = 68)... so now your transactions is 1776 + 68 + 10 = 1854 bytes!  even with the same 100 sats/byte fee, your required fee is now 185,400 sats!

I also noted that on your transaction, you didn't actually send all the bitcoins to one address, you got "change" of 0.000029 BTC... what will happen now is that the next time you try to spend ALL your coins, you are going to have another ridiculously small amount of 2900 sats that will require an extra 148 bytes in a transaction... at 100 sats/byte, you would need to pay 14800 sats to send only 2900sats!! you see the issue??? 

The more tiny amounts you try to include, the higher the fee you're going to end up paying... so stop playing with dust amounts... don't receive them if you have a choice. If you need to consolidate them all, just accept that either you will have to pay a HUGE fee, or you can use a tiny fixed fee and wait for a week to get the transaction confirmed.

Your wallet isn't stolen... It would appear that MultiBit HD has been broken by a commit to bitcoinj where they are now storing a "version" field in transactions... MultiBit HD does not use this field, so when it is calculating the transaction hash and comparing it to the actual transaction hash, it doesn't match... The code throws an Exception, and you end up with this rather unhelpful "Password did not unlock the wallet" error...

If you look in the log, you'll probably find an exception like this:


Restoring from the Seed won't help because as soon as it downloads the "broken" transaction again... your wallet will become "corrupted" again. The only solution I have been unable to come up with, is to import all your private keys to another wallet (like Electrum)... NOTE: you cannot use the seed as MultiBit HD isn't using the same BIP32 derivation path as any other wallet as far as I know

To get hold of all your private keys, you need to use an offline version of: iancoleman.github.io/bip39/ (follow the instructions at the bottom of the page)

- Enter you seed, goto BIP32 tab, select MultiBit HD as client, and then keep generating addresses/private keys until you are sure you've got all your addresses with coins...
- THEN you need to go back to BIP32 tab, select custom client and set Derivation path to m/0'/1 so you can then check all your change addresses as well...
- Once you have a big list of private keys for all your receive AND change addresses... import them into the wallet of your choice.

I've also written a python script that will hunt through your "mbhd.wallet.aes" file and look specifically for transactions in the UNSPENT "pool" and show the output addresses and amounts for those transactions, which should hopefully be a short cut to finding just the addresses/private keys with coins in them...

Feel free to PM me if you like... I helped another user start recovering his coins from a broken MultiBit HD wallet earlier tonight  

NOTE: I don't need access to your seed, wallet file or wallet password... you can do it all on your own PC

I already helped servi295 start recovering his coins... Hopefully, he'll vouch for me

Yes, yes there is... MultiBit HD is basically broken at this point... you can recover your coins, but it is a long, tedious process... just ask servi295

It is definitely related to that issue... MultiBit Classic is not compatible with newer transactions... following those links you posted earlier to the Google Groups... I found the github commit you were talking about: https://github.com/bitcoinj/bitcoinj/commit/be09b620626681c9e51a211ee314a34cb7958a12

In this commit, they are now setting the "Version" field inside a transaction and it is included when calculating the transaction hash value... however, MultiBit is ignoring this field... so when MultiBit calculates the hash value of the transaction it gets "abc", but the hash value stored in the transaction (including the version) is "xyz"... so it fails rather ungracefully and then MultiBit (HD anyway) gives out the rather generic "Password did not unlock the wallet" error and refuses to load up the wallet.

The only way for this to be fixed, is for MultiBit devs to start using the new version of bitcoinj and start using the Version field...

I think I have figured out a solution for exporting private keys from MultiBit Classic... and I am fairly confident that I have a process (albeit quite tedious) to work out which addresses generated within a MultiBit HD "Seed" have unspent transactions and how to get the corresponding private keys for them...

That's because of the very small amounts of btc you are trying to send... 5500 sats, 5100 sats, 6297 sats etc... Your transaction has 12 inputs and was over 1800 bytes... that makes it almost 9 times the size of a "standard" transaction...   you need to stop accepting dust amounts of btc into your wallet or you will face the same issue every time you try to move your coins around.

If you didn't enable "Replace-by-Fee" (not even sure if that was available in 2.7.10), then your options are:

1. Wait... The transaction will confirm or be dropped from the mempool (Probably takes over 72 hours if no-one rebroadcasts your transaction)
2. Try and get a miner to include it (free: ViaBTC or Pay: the btc.com "push TX" feature or PM ther users macbook-air or Quickseller)
3. "Child Pays For Parent" - try and create a transaction that spends the unconfirmed output and that has a massive fee that results in an average fee of both transactions being ~200 sats/byte. Given how large your transaction is, it is going to need a fee of like 350,000+ satoshis (0.0035 btc)... assuming that it would only use 1 input.

Thanks for highlighting this! It all makes sense now...

MultiBit HD also seems to be suffering from the same issue... There have been a large number of users around here getting the "Password did not unlock the wallet" error with the associated "Transaction did not deserialize completely" error in log.

I had got as far as figuring out that it was a hash conflict, but couldn't figure out why the computed hash was different... obviously adding in a new field will cause that

In the meantime, the only way to get access to your funds would be to import the private keys to another wallet... I've figured out a method for MultiBit HD, as you can use the BIP39 tools to derive your keys from the seed... but I've not looked at Classic as yet... hopefully the wallet file can be decrypted in a similar fashion to the HD one...

If you are using Electrum... which your usage of "dynamic fees" would tend to suggest... you can simply set up the transaction on the "Send" tab along with fee... but instead of using the "send" button, click the "Preview" button... this will show you the Inputs/Outputs it will use/create and also the transaction size and fee it is going to use etc

Ok, well you continue to refuse to give us the TXID for some reason... so all I, or anyone else, can tell you from the information given is that ~83 sats/byte, when the recommended was 200+ means that your fee was classified as "low" and would therefore delay your transaction being confirmed...

it seems the number of unconfirmed transactions is slowly reducing, so your transaction may confirm in the next 12-24 hours... but no guarantees...

However, there may be additional issues like double spend and/or unconfirmed transaction chains that we can't see because we don't have the transaction ID... 

Huh... I did not notice that... :/

Honestly, I have no idea... maybe related to different SKS versions? or different keyservers? or perhaps it is because ThomasV updated his key and added in a new email address? I honestly don't know...

I have to admit that my knowledge of PGP is relatively limited on how or why the key files would be different, but the beginning and end bytes of the key would be the same??

We will need to see the transaction ID, so we can determine:

1. What the "data size" of the transaction is (ie. how many inputs and outputs), and therefore what the transaction fee calculated as "satoshis per byte" actually is
2. If the transaction is relying on any other unconfirmed transactions
3. Any other possible issues (Double Spend etc)

Ok... well I have no idea what service he is using... Most wallets do not even include that information (AgentID, Conflicting Transaction# etc)... It is just weird. Did he give you a link to a website or something that he wants you to take a screenshot of?

As for wallets themselves, there are "online" or "web" wallet services like blockchain.info, Xapo, bitpay, coinbase... (Most bitcoin experts will advise you to avoid web wallets, as most don't actually give you complete, proper control of your bitcoins, private keys and/or fees which can lead to issues).

You can also get apps for iPhone or Android... and there are desktop applications for Windows, OSX and Linux...

You should have a read here: https://bitcoin.org/en/choose-your-wallet

My personal recommendations would be:

Desktop: Electrum (has versions for Windows/Linux/Mac)
Android: Mycelium or Electrum
iOS: maybe BreadWallet?

Fair enough... honestly, if he doesn't want to use an Escrow service, that is his perogative I guess

I think he would be better off asking you to sign a message from your bitcoin address that contains at least the minimum amount of bitcoins required for the transaction... that proves that you own the address, and that it has the coins in it. (He can also check the address on a block explorer to make sure you don't move the coins).

I can't recommend that you use bitpay.com... I don't recommend you use ANY web-based wallet... but the wallet you want probably depends on whether or not you intend to continue to use bitcoins after this particular transaction.

I have no idea what he means by "Conflicting Transaction#"? But once you buy your bitcoins and have them sent to whatever wallet you decide to use, you will be able to provide him with the transaction number without worrying about safety. He won't be able to steal your bitcoins or anything. All transactions on the blockchain are publicly viewable anyway... and the contents of any given bitcoin address is also publicly viewable.

Whatever you do... DO NOT send any information relating to "private keys" or "seeds" or "wallet words" to anyone...

Where?

I don't see any output from your Log File... without showing us what is in the debug.log file, we have no way of knowing what your issue is... :/

Probably a glitch with your wallet provider... like you clicked "submit" twice really quickly or you pressed the back button in your browser and it resubmitted it or something like that... your wallet really shouldn't allow that to happen... 

Anyway, one of the transactions now has 2 confirmation... so chances are that: 466a3a2eb7bcf19c7725ac675d804af6ee768516529a552ca04f36d663c6348b

is going to be the one that is accepted... and the other transaction: 4ac6f2fc291a6baaf18421eb30095b68388428a9756a19a8c2adf73d9f8b8345

will eventually get dropped... it is most likely to happen after the other transaction gets like 6 confirmations... maybe sooner.

So he wants you to prove you have enough bitcoins to pay for the product in your wallet? or is he wanting you to use an Escrow service?

- If it is the former, the guy is an idiot... a very trusting idiot...
- If it is the latter, then he is being smart...

Note: In the list of addresses shown, On the "Addresses" tab, you may need to expand the "Used" and/or the "Change" sections if you want to see all the addresses...

I suspect that given:

1. All the issues with unconfirmed transactions this week
2. The ongoing SegWit vs. BU saga
3. Increasing fees

That the most likely emotion currently being evoked in a lot of users is a variation on this:

If the fee you use (calculated in sats/byte) places your transaction in the top 1MB of transactions in the mempool... chances are good a miner will include your transaction in a block...

You can see the fee spread vs. total size of transactions here: https://btc.com/stats/unconfirmed-tx



Bear in mind, that others are coming along adding transactions after you while you wait for a block to be mined... so don't aim too close to the 1MB mark, as if you do, and 10,000 people come in and put a higher fee than yours, you might end up dropping down the list...

In the screenshot above, if you were to put in a fee of around 160-170 bytes, you'd be around the middle of the top 1MB of unconfirmed transactions... That should help increase your chances of getting in the next block mined. Of course, nothing is guaranteed... but it will help.

Also, you can see how if you use a fee of around 100-120 sat/byte, you going to end up in the 2MB to 8MB range... and could be waiting for quite a few blocks before your transaction gets confirmed.


EDIT: And this screenshot illustrates my point about not aiming too close to the 1MB mark... by the time I finished writing up my post, the distribution now looks like this:

You sent a transaction in the middle of a period of massive network congestion (>100,000 unconfirmed transactions)... when recommended fees were over 200 sats/byte... with a fee of 100 sats/byte... and every second thread in this subforum is about transaction confirmation delays... what exactly did you think was going to happen?

Keep trying the ViaBTC accelerator... and wait... your transaction will either confirm, or it will get dropped...

If it is super important that it gets through, try "Child Pays For Parent" using the change that got sent to 1HRqr8EdvE5Y1P7SvLpzJWe9Zxa46oN6XA and calculate a fee that will result in an average of 200 sats/byte for both transactions and it is likely that a miner will pick them both up.