MultiBit

[Tittiez]

Awesome, thanks Jim I received what was left in the wallet.

[1714896722]

1714896722

[1714896722]

1714896722

[1714896722]

1714896722

[1714896722]

1714896722

[jim618]

Cheers Tittiez!
Quite good fun trying to hunt down where the private keys were in those megabytes of wallet.

I will write up how to extract the private key from MultiBit wallets in case it is useful to other people and post it here.

[jim618]

To extract the private keys from the current MultiBit wallets is not for the faint of heart!

First you will need a hex editor. I used HexEditor for the Mac.

Here is a typical block of bytes that you are searching for, containing the all important private key and the public key:

Code:

78 70 00 00 00 20                                           << The 20 is the length of the private key in hex
                  e5 d4  25 0e 2e 45 ff 82 4e ff            << private key in hex
3b 49 da 1a 4e 9a 4c b5  3f 71 cb 8f b6 80 46 10            << private key in hex 
e1 ed 1a 7b 16 28                                           << private key in hex
                  78                                        << ignore this byte
                     75  71 00 7e 00 11 00 00 00            << search bytes
41                                                          << length of public key in hex
   04 19 0a 40 a0 a7 d0  48 c8 79 eb 93 e9 63 48            << public key in hex
82 09 ea ab 65 13 95 c2  7f 21 c2 0e 79 a0 24 18            << public key in hex
05 62 55 34 fc a2 bb 7f  04 46 ce 23 43 89 06 52            << public key in hex
9a 0c 32 11 c5 ef 1b e1  d4 ca 16 fc e3 48 29 73            << public key in hex
10 14                                                       << public key in hex
      78 73                                                 << public key post amble

In reality your hex editor will show them all together - I have added the line separations just for clarity.

To identify a block of bytes containing a private and public key, seach for the hex "75 71 00 7e 00 11 00 00 00 41". You are actually searching for a boundary between the private key and public key stored in a serialization of the class ECKey (which contains the private and public key).

The "41" is the length of the public key (=65 in decimal) so look forward 65 bytes. It should look completely random. This is the public key in hex. After these bytes there should be "78 73".

Before the search string is a single byte which is usually "78" but does seem to vary. Ignore that. Look backwards for 33 bytes and you should see a "20". This is the length of the private key (=32 bytes in decimal). The 32 bytes following the "20" are your private key in hex.

Result!

Repeat this search through your wallet until you extract all the private keys. You will sometimes get false positives in that you get a search hit but the bytes around it have a different structure. You can ignore these.

In Java this hexadecimal representation of the private key can be added to a bitcoinj wallet using:

Code:

Wallet newWallet = new Wallet(NetworkParameters.prodNet());
ECKey key1 = new ECKey(new BigInteger(1, Hex.decode("e5d4250e2e45ff824eff3b49da1a4e9a4cb53f71cb8fb6804610e1ed1a7b1628")));
newWallet.keychain.add(key1);

A useful check that you have not extracted garbage is to print out the bitcoinj wallet using toString() and look at the public key in hex. It should match the public key you extracted from the wallet at the byte level.

You then need to replay the blocks from the date of the first transaction for that address to get the transactions. I just looked up the address in blockchain.info and looked at the first transaction to see what this date was.

[jim618]

We've had over a 1000 downloads of MultiBit in the last month!

Github download statistics

I think it is the new clients page on http://bitcoin.org/clients that has increased the download rate.

:-)

[Tittiez]

Seems blockchain.info changed the way URL's work for transactions. Might wanna fix that.

[jim618]

Hi Tittiez,

Thanks for that headsup.

The URL for, say, tx df06784a5d5d313ddc107fc5c92ebf975f13b9c8500e0897b49a0e3848ee8114

has changed from:
http://blockchain.info/tx-index/df06784a5d5d313ddc107fc5c92ebf975f13b9c8500e0897b49a0e3848ee8114

to:
http://blockchain.info/tx-index/3578082/df06784a5d5d313ddc107fc5c92ebf975f13b9c8500e0897b49a0e3848ee8114

I will ask piuk about what the extra field is and update it if possible. I think it has changed in the last 24 hours as I tried it ok last night.
The transaction lookup for blockexplorer.com in the MultiBit transactions details dialog still works ok.

Cheers

[Tittiez]

I will ask piuk about what the extra field is and update it if possible. I think it has changed in the last 24 hours as I tried it ok last night.
The transaction lookup for blockexplorer.com in the MultiBit transactions details dialog still works ok.

Cheers

Seems to be the transaction number. See:

http://blockchain.info/tx-index/3578085/
and
http://blockchain.info/tx-index/3578086/

Are seconds apart. They don't require the transaction hash either.

[jim618]

Yes I think you are right.
Looks like piuk has put in an index for the unique number of the tx (presumably it is faster).
That would scupper me as I do not have that number to do a look up MultiBit -> blockchain.info on.

I have messaged him anyhow so will see what he replies. 

[piuk]

Hi Tittiez,

Thanks for that headsup.

The URL for, say, tx df06784a5d5d313ddc107fc5c92ebf975f13b9c8500e0897b49a0e3848ee8114

has changed from:
http://blockchain.info/tx-index/df06784a5d5d313ddc107fc5c92ebf975f13b9c8500e0897b49a0e3848ee8114

to:
http://blockchain.info/tx-index/3578082/df06784a5d5d313ddc107fc5c92ebf975f13b9c8500e0897b49a0e3848ee8114

I will ask piuk about what the extra field is and update it if possible. I think it has changed in the last 24 hours as I tried it ok last night.
The transaction lookup for blockexplorer.com in the MultiBit transactions details dialog still works ok.

Cheers

Oops, This was an unexpected side effect from a change I made. Both links are working again now.

Looks like piuk has put in an index for the unique number of the tx (presumably it is faster).

Yeah this is a database index used to save a little memory. Each input and output needs to reference the transaction so rather than have a 32 byte hash included each time it is cheaper to assign the tx a unique 4 byte integer and use that as the PK.

You can also use:

http://blockchain.info/tx/df06784a5d5d313ddc107fc5c92ebf975f13b9c8500e0897b49a0e3848ee8114

[jim618]

Hi piuk,
Thanks for supporting the original format of tx URLs once more.

:-)

Jim

[Kazimir]

Been using MultiBit for a while now, but I'm having problems with transactions I send.

Receiving works OK, but if I want to send coins to another address, they just don't seem to get confirmed. At least not according to MultiBit. If I look up the details on blockchain.info, it's confirmed all right (so the transfer is processed properly by the network) but somehow MultiBit doesn't pick up. Not even after 24 hours, and restarting MultiBit several times (and giving it pleny of time to sync).

Note that it *does* pick up confirmation of transactions I receive from others.

So far I have been able to 'fix' this by using Reset blockchain and transactions. It takes a (quite long) while to replay all the blockchain data and then my wallets are up to date and all transactions appear as confirmed.

What gives?

[jim618]

TBH it sounds like a bug.

You get the zero confirmation on the send when it gets put out to the network(which sounds like it is working) and then the confirmation comes from the block in which the transaction appears in. If MultiBit does not see/ process this correctly when it comes in from the network then the transaction would not confirm.

The fact that it is on the blockchain means it was correctly transmitted out to the network so I suspect it is on the receive side.

Could you PM your log files (in your user data directory/ MultiBit/log) and I will have a look. If you can engineer an example transaction where it has not confirmed (say by sending a small amount to a friend) and let me know the transaction details that would help me identify it in the log.

Oh and let me know which version you are using and the operating system in case it is related to that.

Jim

p.s. It is not a solution I know, but you can save a bit of time in the 'Reset blockchain and transactions' from choosing the option 'Specify reset date'. Then choose a date, say, one day before when the first unconfirmed transaction appears. It will work the same as doing the whole wallet but you can save a lot of waiting.

[CrownCloud]

Any way to export all my transactions info to a CSV or XLS file ?

[jim618]

Sorry no - not at the moment. It is on my list on UI enhancements to do but I am concentrating on the lower layers at the moment.

I will probably have an export to CSV as that is simpler to do.

[Lumpy]

I like this client quite a bit.

I had a couple of small suggestions: the first was for watch-only wallets, but I see from the thread that it's on your todo list.

The others:

1) Customizable decimal places in display. I don't think 8 digits will overwhelm anyone, but if 4 sounds more friendly, maybe add an option to preferences that defaults to 4?
2) A header that shows the current wallet along with (or after) its balance. I know that the wallet is highlighted on the side, but I think it would be nice to see: "3.0000 BTC - Spending" or something of that nature.

[jim618]

Hi Lumpy,

Thanks for your comments and suggestions.

Yes I want to improve the options with the numbers presentations. There is already a suggestion to add support for commas as decimal separators and number of decimal places would be good to do at the same time.

The current wallet description and filename is shown on the top of the window e.g

MultiBit - your wallet description - c:/Jim/pettyCash.wallet

I put it in the window title as it is more conventional and there is more space there.  Also when you have the MultiBit window minimised it normally appears in the minimised icon title.

I imagine it will be a month or so before I do another round of UI improvements (other than wallet related ones).

Thanks for your input.

[CrownCloud]

Sorry no - not at the moment. It is on my list on UI enhancements to do but I am concentrating on the lower layers at the moment.

I will probably have an export to CSV as that is simpler to do.

Nice CSV sounds good Awesome work on MultiBit !!

[Lumpy]

Thanks for the consideration, Jim.

Does MultiBit have a minimize to tray option? If not, any plans to add one?

[jim618]

It does not have a minimise to tray at the moment.
I seem to remember something in the Java System class improvements about minimize to tray so will put it on the list of things to look at.

Cheers

[Kazimir]

p.s. It is not a solution I know, but you can save a bit of time in the 'Reset blockchain and transactions' from choosing the option 'Specify reset date'. Then choose a date, say, one day before when the first unconfirmed transaction appears. It will work the same as doing the whole wallet but you can save a lot of waiting.

Thanks, yeah I found out about this later, helped me save time.

Actually, I'm not sure what happened, but after I tried again, this problem did not occur anymore. I've sent several more payments later on and they were processed normally (I mean they also appeared as 'confirmed' in MultiBit within reasonable time).

Anyway I'll keep checking, and if it shows up again I'll let you know and send some logs.