load the wallet.dat with wallet-key-tool
save it as Multibit .wallet file


or rename the bitcoin-core dumpwallet file (you get this when using the "dumpwallet" command in the bitcoin-core console), rename it so that it has .key at the end and then import it into Multibit using the import function (its the same file format)

define: "not working"

you can backup either one. Each one of them alone contains all keys, so only one of them is needed to restore access to your coins.

The .wallet you can just open (file -> open), the .key needs to be imported into a newly generated wallet. The .key file can also be used to merge two wallets into one because it can be imported into an existing wallet.

The key file (when you decrypt it manually) is a plain text file, so theoretically you could import it elsewhere even if you don't have an installation of Multibit. It has the same file format as the file you would get from bitcoin-core when executing the dumpwallet command and can be imported by all programs that support this file format (Schildbach, Bitcoin-core, Multibit, probably a few more).

You should also keep a copy of the .info file, its not strictly needed but it adds some convenience, it contains the labels you gave to the addresses, its easier to interpret your old tx history if your addresses keep their names. But this is optional.


I personally backup my .wallet along with its .info file instead of the .key because I will always have a Multibit installation around (or my own wallet-key-tool converter program which can read/write them all)

No, coinbase is not an alternative. There are other local wallet apps and each of them is to prefer over a web service like coin base. Before you make a fatally wrong and dangerous decision (such as giving away your bitcoins to someone else to hold them for you) you should understand and compare the risks. A sync problem in Multibit is zero risk for you, its just a minor temporary annoyance not being able to see your latest transactions immediately due to failure to download them from the network, thats what the "reset block chain" button is there to try downloading them again. Nobody can lose or has ever lost bitcoins from a sync problem, this is just not possible due to the way bitcoin works.

If you are now misinterpreting this minor user-interface glitch as a greater risk as giving your precious private keys away to a third party with remote access from all over the world and with dangerous exposure to inconsistent US regulatory agencies then this might later prove to be a huge mistake. I recommend you keep your BTC in Multibit where they are safe and controlled only by you and not share them with a whole bunch of people you have never met. Even if this means you have to click the "reset" button once every few months to force downloading the tx history if it doesn't download on its own.

Mike,
from the broken blockchain.info importer:
How could that ever generate a key that does not match the address? The address from the json file is not even used and the pubkey of the new ECKey will be set to null in this constructor and because of that it will then be calculated from scratch from the private bytes. This problem (if it even exists) must be somewhere else.

Why not? Its published for others to see, so its public by definition.

No. Export works perfectly. there was an issue with import of blockchain.info aes.json files because the blockchain.info file format and its old import code (which has been removed) is screwed up but it could only lead to loss if you deleted old backups or generally didn't care about making backups or at least verify that everything is ok and you have new backups before deleting old backups. Backup (export) itself is working perfectly.

Now lets try something else (please first make sure you find the exact location of the .wallet file in explorer, remember where it is, maybe even make a copy of that file to a safe location so you won't accidentally delete it)


The following requires you to trust me not to be a malware producer intending to steal your coins, It is ok if you don't want to do that, you don't have to! Go to this website https://github.com/prof7bit/wallet-key-tool/releases and download wallet-key-tool. Start it.

* Click the load button, find your .wallet file open it, enter password to decrypt.
* It should show you a list of your 3 addresses and their keys.
* right-click each of them and choose "fetch balance and creation date from blockchain.info", verify that the numbers are correct.
* Click the save button, choose "Multibit wallet" as file type and a convenient folder and file name where you can easily find it, it will not allow you to overwrite your existing wallet, it will save a new wallet file.
* open Multibit
* close the existing wallet file (file -> close).
* click "file->open"
* open the newly created .wallet file from above
* watch it sync (do not reset, it will sync on its own) and balances should be ok.

Yes, you are supposed to be able to receive to all receiving addresses on the request tab. Every wallet can have multiple receiving addresses. You keep using the term "payment id", this terminology does not exist in Bitcoin, I suppose you mean "bitcoin address" or "receiving address"? Lets get the terminology straight:

• on the left side panel you see wallets. A Wallet is a collection of receiving addresses. You can manage more than one wallet in Multibit, you can switch between them, each one is represented by a *.wallet file, each wallet can have as many receiving addresses as you want.
• on the main panel in the "request" tab at the bottom you see the list "your receiving addresses", these are the bitcoin addresses contained in the active wallet (the wallet that is currently selected in the left side panel if you have more than one wallet or the only wallet if there is only onel), a payment to any of these addresses should show up in the transaction list of that wallet and add to that wallet's balance
• if you switch to a different wallet on the left side then you will see how receiving addresses, transaction history and balances are switched also to show the information for the currently selected wallet

If you have more than one wallet (on the left side) then it is possible that only one of them is suffering from this out-of-sync condition. Close all other wallets (file->close), open only the "broken" one (file -> open), apply the above mentioned full force sync method to the broken wallets individually.

Please check the clock on your computer, check date and time. If its accidentally wrong then:

• quit Multibit
• set the clock correctly, make sure that year, month, day, hour, everything are correctly set to today plus/minus a few minutes.
• restart MultiBit and watch it synching on its own, do NOT click "reset block chain", this would mess it up, just let it sync on its own.

If its still not correct then here is the procedure how to force-sync everything

• quit Multibit
• set the clock to some time in February 2009. do not choose any date before 2009-02 or it won't work, you can choose a later date if none of your keys is that old but not earlier, so if you are around only since 2012 then choose some date in 2012 before you started using this wallet.
• Start Multibit
• Reset block chain
• Wait until it says "Synchronizing", all tx will disappear but there will be no progress, this is expected, syncing will hang
• Quit Multibit
• set the clock to today, set it to the exact date and time of today
• Start Multibit
• Do NOT reset the block chain now, instead just watch it sync on its own.

After this your wallet should be synced correctly and show all tx

-----

@jim618: last week when looking at the code it seemed to me (if I remember correctly and if my interpretation was correct, I only had a cursory look at it) that when the user clicks "reset block chain" it will to the following:

find the date of oldest transaction in the tx list, if found then use that, ignore creationTimeSeconds. If no tx is found then use earliest creationTimeSeconds (oldest key). If its zero (undefined) then [not sure, probably do the wrong thing]. Problem is: In MultiBit the creation time of the keys is always zero! As soon as the wallet has no tx anymore it does not know from when to sync! And even worse: if it has some tx but is for whatever reason missing the oldest tx then it will never be able to correctly sync! It doesn't actually matter why it has missed a transaction, reset is supposed to fix this condition without knowing the reason but it can't!

With the above way of hitting "reset blockchain" while the clock was wrong a few times I managed to bring my old wallet (tx since 2011) into a state where it had only the last two tx from a few months ago and flat out refused to sync any earlier date, it considered these as the oldest tx in my wallet and synched only from this date onwards! I had to apply the above crude procedure to force-sync it from 2011 again. I think this is the bug that breaks reliable wallet syncing! Either because all keys are stored with creation date = undefined or because the algorithm to determine sync date is fundamentally flawed. Please bring back the calendar control to be able to override the wrong decisions of this heuristic and manually choose a date in the past to force-sync.

This is strange, are they visible on blockchain.info with at least 1 confirmation?

Try resetting the block chain (last item in the tools menu)

Sometimes for some reasons Multibit doesn't receive all tx records it asked for from its connected peers and therefore Multibit simply does not "see" the transaction although it exists. This means you have received the money and everything is fine, just the wallet app did not receive the needed information for some reason (network problems, other connected nodes having problems, etc) and you just can't see it and it appears like it is missing. This is not dangerous, only annoying but it happens only rarely and can easily be corrected.

Resetting the block chain will make it ask for the needed blocks again (and this time it will most likely ask a bunch of different nodes, not the same ones again) and if nothing else is fundamentally screwed up then the "missing" transactions should become visible.

Yes, Xtend is for Java what CoffeScript is for JavaScript (so it should actually be called "Coffee"). The only downside is that other than Eclipse there is zero IDE support (but the Eclipse support is excellent). But I would not try to reuse the generated Java code directly, sometimes its readable but when using lambdas and some of the syntactic sugar the generated code quickly becomes impossible to understand. The wallet.dat parsing code is actually totally imperative and straightforward, so it should be easy to translate it manually to Java without first trying to make sense of the Xtend compiler output, most of the time you would just need to add all the missing type declarations and a semicolon to the end of every line and 90% of the work would be done.

...decrypt it and and create c.g.bitcoin.core.ECKey instances from the keys.

If anybody of you ever felt the urge to parse a Berkeley database (wallet.dat) without linking against libdb, and use the keys in your bitcoinj based application: here is some inspiration: https://github.com/prof7bit/wallet-key-tool/blob/master/src/main/java/prof7bit/bitcoin/wallettool/fileformats/WalletDatHandler.xtend

 

You can import the Schildbach backup file directly into MultiBit, just change the file extension to *.key so it can find it in the file dialog. This is very useful when your phone is stolen, if you have a Multibit installed on your Desktop and ready to use and are familiar with it then you can quickly import the Schildbach backup on your PC and send all funds to a safe address before the thief figures out how to do it. But you should not use the same keys in both applications in parallel, this will cause strange effects (coins magically disappearing in the other wallet), do this only if you want to permanently move all keys from A to B.

The keys don't match? Did you decrypt the file and compared the keys inside or what do you mean? The file itself will always be different because a random initialization vector is used during encryption. This does not mean the contents (after decryption) differ. You can see what is actually inside the file by opening it with wallet-key-tool (or by manually decrypting it on the command line with openssl).

It is possible without any external tools and its actually pretty simple, you also don't need pywallet, this is more complicated than helpful in your case. In bitcoin-core find the console (help -> debug window -> console)

enter these two commands (or only the second one if you don't have a password):


The "60" means unlock it for 60 seconds, this is the time you have to enter the second command. The password goes between the quotes "", if you don't have a password then you only need the second command.

If no error has occurred then you should be able to find the "dump.key" file somewhere in your home directory (don't know exactly which this is on Windows but you could either search your HDD for this file or instead of you could use a fully qualified path like for example to dump it to the root folder of c:\.

This works even when its not fully synchronized.

After this you can quit bitcoin-core and start Multibit. In Multibit you

* go to Tools->import private keys
* enter your Multibit password
* click import from and choose the "dump.key" file
* click "import keys"

This will import more than hundred keys into your wallet, most of them will be change and reserve addresses of bitcoin-qt but you need them all!

Wait for Multibit to sync. After it has synched 100% check the wallet balance is correct.

Unfortunately you will lose the address labels. If you want to preserve the address labels then you could first import the "dump.key" with wallet-key-tool and then export it from there directly as a new multibit .wallet file (which you don't need to import but can directly open in Multibit), this will keep all the address labels and mark the change and reserve addresses as "(change)" and "(reserve)". You can reuse all these reserve addresses if you want, just give them a different label and use them as receive addresses to request payments to you.

After you are done don't forget to add a strong password to your wallet (if not already done so) then delete the dump.key (because it contains unencrypted keys and you don't want to have that laying around on your HDD), then empty the trash and then find a tool to wipe all free space on your HDD to remove all traces of unencrypted keys from your HDD and unused sectors.

don't delete your old wallet.dat before you are sure it worked 100%, if it worked then don't use the old bitcoin-core wallet.dat anymore because this would add new change addresses, you must make a decision: either from now on use these keys only in the new imported Multibit wallet and don't use the old wallet.dat anymore ever or leave everything as is and don't move any keys at all. Under no circumstances use the same keys in parallel in both wallets!

question about "hexsec" and "secret"

consider this dump of an unencrypted wallet: (don't worry, I won't store bitcoins at these keys, I'm just experimenting)


Why are "secret" and "hexsec" only 16 bytes?


This is the same key after loading the wallet with bitcoin 0.9 and encrypting it (and decrypting again with pywallet)


It almost looks like the first version was just cut off in the middle.

Another question: Is there any documentation about the various elements of the json that is produced with pywallet?

* For example what is the meaning of the "pool" array, its repeating all the addresses but without their keys but seems to contain additional info, what is the rationale behind structuring it that way and not just put all info about a key into one object?
* what is the empty ckey array at the beginning of the dump?

I don't understand your problem.

Blockchain.info and Multibit (from your screen shots) show the exact same balances and transactions, there is not a single Satoshi difference. You had around 0.2 (even 0.34) around 16 Mar, this was 2 months ago, you have spent half of it since then, its all on blockchain.info and also in Multibit, you can use a pocket calculator and go through the transactions backwards in time to see exactly how much you had at what time.

if you compare the tx history in multibit line by line you will probably find that in one of them some tx are missing, probably the oldest ones, so start comparing with the oldest tx to save time. This is because it did not completely sync the block chain. The method I suggested was to force a fresh wallet with these keys to sync from the beginning (or from the earliest time you used these keys onward).

Older versions of Multibit allowed you to manually specify a date from where to sync when resetting the block chain, newer versions are trying to determine this automatically from the time of the earliest transaction in the wallet and I suspect this algorithm is flawed, especially in the presence of imported keys. From looking at the code I got the impression it is trying very very hard to avoid unnecessarily syncing too far back. Therefore my suggestion to make a fresh wallet with imported keys that have explicitly set their creation time early enough to enforce a sync over the needed time, no matter what.

The numbers on blockchain.info should show you how many BTC you really have, these numbers and the tx history shown there can be regarded as authoritative. Your goal is to bring your Multibit wallet into a state where it will show the exact same numbers. Any other versions of the same Multibit wallet showing different numbers can be ignored because its not correctly synced and missing some tx and if it refuses to sync then its broken.

Therefore import the keys (with their creation dates set early enough) into a brand new empty wallet and let it sync. Then it will show the exact same balance and same tx history as blockchain.info and these numbers will be authoritative!

If your wallet was incompletely synced all the time you probably thought you had more BTC than you really had. Thats probably also the reason the last tx did not go through, You and Multibit both believed you still owned these coins and tried to spend them but you have spent them long ago already and neither you nor Multibit can remember (because at some earlier time the sync must have been messed up) and the tx was not accepted by the network.