Yeah its proparbly more of a feature for the retail-thing

I have been having a bit of fun tonight seeing if I could get a MultiBit wallet and a http://blockchain.info wallet to both contain the same private keys.  

The idea is that with the same private keys they should both see the same spends and receives of bitcoin together in realtime.  The two wallets should both change in lockstep.

It works !

The trick is to create the wallet first in MultiBit, export the key(s) and then import the keys into your blockchain.info wallet.   You also want to delete any other keys in your blockchain.info wallet - obviously move the bitcoin on those keys out before you delete them.

Here are two screen shots with the same transactions appearing in the two user interfaces:

The BTC and transactions in MultiBit:
http://multibit.org/postImages/multiBitBlockChain.png

And the same in blockchain.info:
http://multibit.org/postImages/blockChain.png

Neat!

Hi HanSolo,

Thanks for pointing out that scenario. To be honest the various scenarios of duplicate keys needs much more testing before it is generally usable. For instance I notice with the current MultiBit code if you have the same key in multiple MultiBit wallets zero-confirm spend transactions do not appear in the 'other' wallet - only when the block appears does the transaction get in.

I imagine the code in other wallet providers will need work on them too for the scenario of a spend transaction for one of their wallet's keys that comes in from the bitcoin network. I would not rely on this functionality for your production systems yet.

Re: opening up MultiBit. At the moment the only interface out of MultiBit is to the Satoshi clients. We have started some preliminary work on connections between MultiBit and the exchanges and there is also the sister project of adding Open Transactions into a MultiBit code fork.

Gary Rowe has been working in a project called MultiBitMerchant which will be our web offering with a catalog etc.

Mainly because MultiBit will be an 'end user' system with, eventually, a keystore of the various private keys and credentials to connect to other systems I was not planning to add a programmatic interface to MultiBit itself. The main reason for this is from the security perspective. It is to minimise the attack surface.

Now that there are bots searching for and attacking bitcoind RPC interfaces that people open too wide it seems prudent for a end user client like MultiBit to keep it's attack surface as small as possible.

If someone has something they want to implement that was more 'server-ey' based and use the MultiBit code as a basis I have no problem with that. Just so long as they brand it as something other than MultiBit and spend the time and effort on securing their APIs.

Bug feedback:
On my MBP,when the Multibit app is open but the battery runs out (loss of power on computer event),I lost my Bitcoins in this app.I only lost 0.009 BTC (so not much but still concerning).I think that a more rigid fail safe system needs to be implemented to guard against loss of power (auto ghost copies of the wallet file on different areas on HDD.I hope that this system would like clone the main wallet,then unload the main wallet and run everything from hte ghost copy so that if the ghost copy is corrupted by loss of power,it can recreate another working copy from a known good wallet file and the cycle repeats as much as needed).

I'm running Multibit 0.30 Snapshot version.Implement a recovery system that can detect a loss of BTC (corruption) then offer a step to restore the BTC (unspent BTC being lost).

Good news Jim.I've tested this and I can report success with this.Turned out I had 0.0342BTC (as 0.02BTC was sent to non working address and 0.009 was 'lost' when MBP battery lost power).

This is a very nice app for me.Just gotta work out those bugs.I feel that bugs like that are important to fix as they can affect laptop users (PC+mac) as they are most likely used on battery and when loss of power occurs (battery runs down) and the file doesn't save or no backup is made,info can be lost.

Jim Burtons talk at the bitcoin conference in Prague (for those who missed the post elsewhere)

https://bt.irlbtc.com/view/62176.0

(other eurobit talks listed here: https://bt.irlbtc.com/view/40272.msg725830#msg725830)

Hi Cobra,
There are a few things that Multibit uses that are specific to Java 1.6 so that is the minimum JVM specified.

The list if what was in Java 1.6 is here:
http://www.oracle.com/technetwork/java/javase/features-141434.html

The drag and drop was improved in 1.6 and file locks I think were made more reliable.
The integration with the system look and feel was improved in 1.6. - this improves the screen redraws.

Jim

A customer has a tx that seems to not be broadcasting. How does Multibit handle this? Will it go eventually? Should he reload... what? And try again?

I thought you would be interested in some future MultiBit development work we are starting up.

Tim Molter is a Java developer who is writing a library to integrate with the various bitcoin exchanges.
You can get more details of his project here:

https://github.com/timmolter/XChange/wiki/Milestones
https://github.com/timmolter/XChange/wiki/Exchange-support


We are planning to use XChange in both MultiBit and MultiBitMerchant, initially to get exchange rate data but later on to provide deeper integration with the exchanges.   (We are still working out what we can and cannot do).

It will be a while before it appears fully productised in MultiBit MultiBitMerchant but it is very interesting work.