After some discussion on the bitcoinj mailing list, I've come round to Foo's point of view in that the wallet master key is not really worth the development effort. The time would be better spent on finishing off the current encryption code and getting it out the door.

This would then enable me to contribute earlier to the Java hierarchical deterministic (HD) wallets coding.
HD wallets are probably going to take over from 'random key' wallets anyhow. Having the mnemonic pass phrase will enable you to recreate the whole wallet (Electrum style) if you need to.

I have been playing around today with the 'seaglass' look and feel.
Whilst it looks very nice unfortunately it does not handle the mouse scroll wheel properly in combo boxes and window scroll bars. It 'kinda' works but not 100%.
I have thus dropped it from the code.


Also, there has been quite a lot of localisation work done over the last couple of weeks (Thanks!)
so I plan to release another live version, hopefully on Monday.

I will include all the localisation work that is done by Monday morning (GMT). There are also some code tidy ups that would be nice to get out but the release if mainly for the localisation work.

Yeah -  I think you are right - Eclipse is a good example where a few custom components improve it no end.

The Java look and feel trys to be everything to all platforms and does not quite make it.

Most commercial apps, as you say, have their own design rules.

I would imagine for the next few months I'll just concentrate on the code and raw functionality and just keep the UI roughly the same.
TBH I am not sure the addresses paradigm is quite right but don't know what to replace it with.

The seaglass look and feel is the nicest I have seen but unfortunately isn't quite ready for production use yet.

I've switched back to the encrypted wallets code branch now.
Whilst forward porting everything from 0.4.18, I have also noticed and fixed:

+ Now only hits currency server if ticker is shown or currency conversions are on
+ Fiat currency fields only shown on Send and Request tabs if/when fiat currency successfully found from remote server
+ Fixed help tab borking MultiBit if no network connection present
+ Removed cacheManager code - no longer supported

I am basically trying to "productionise" the code as much as possible.

Probably the next week or so will be going through all the encrypted wallet code again, working through Mike's review of it (that he did before Xmas) and preparing a pull request into bitcoinj.

Hi HostFat,

Will do - presumably your browser is saying something like 'some of this page's content is unencrypted blah blah'.

edit: Done. There are still a couple of http only links on that page (http://translate.multibit.org and http://lovebitcoins.org but neither of those have ssl certificates).

RE: links - ok good - don't need to worry about those http links.

Yeah - bitcoin addresses aren't terribly friendly.
I think the payment/ invoice paradigm Gavin is spearheading will be more useful for people as then you can track outstanding invoices etc and chase people up for payment. I guess MultiBit will end up looking like a generic accounts software package. That won't be a bad thing as then I can run training courses on how to use it to Accountants. :-)


For the boomerang rule I noticed whilst having a look at your PeerGroup code that I think you have already done a lot of it (minimum number of peers to connect to and number of peers that have seen a tx is already on Transaction Confidence). I was not aware of that PeerGroup code when I did it I must admit as that is a better level to do it at, rather than in the application layer.

Once it is in bitcoinj I can get rid of the application layer code in MultiBit that does it and refactor it to use the bitcoinj code. (Always happy if there is less code in MultiBit to maintain). The UI probably wouldn't need to change at all.


I am a bit behind bitcoinj capabilities at the moment actually. I was thinking of putting in a Network page now that we have ping times (like Andreas has put in his mobile wallet). It is on the ToDo list anyhow.

I'm still getting the it, have you already uploaded ?

Great. Feel free to reuse the code in PeerMonitor.java - it's only small but it's Swing and you could just copy it right into your app.

Yes, protobufs only care about tag numbers, you can rename fields and old messages are still readable.

Protobuf enums are tricky. If there's an enum value on the wire that isn't in your app, the field will fail to deserialize completely. I suppose you can use this to detect wallets from the future by checking if the optional field defaults to some UNKNOWN value, but an int is conceptually simpler.

Hi Cameron,
Yeah sorry should have said.
That new branch of bitcoinj has the refactoring as a result of Mike's comments. It is preparing a pull request for bitcoinj for the encrypted wallets and I am updating the MultiBit code as I go.

Website statistics for multibit.org are now available again.

There is a link in the 'Downloads' panel (top right of every page) to:
https://multibit.org/awstats/awstats.pl?config=multibit.org

Updated hourly.