Topic: MultiBit - page 34. (Read 336309 times)

I have added in a 'pickaxe' icon for coinbase transactions to distinguish them from regular transactions.
Screenshot:



Hat tip to Alan Reiner for the icon idea.

For coinbase transactions they mature slower than regular transactions (120 blocks for a full confirmation) so I have slowed down how quickly the status icon fills in correspondingly.

It will appear in the next live release, which should be early next week.

Thanks for the comment Mike,

The MultiBit version of Sha256Hash only exists now because of that problem from ages ago about there being two different serialVersionUIDs in the wild.

I think at some point I will stop supporting serialised wallets and for any serialised wallets remaining just ask people to download an older version of MultiBit from multibit.org/releases and migrate their wallet using that. There cannot be very many in the wild now anyhow.

Then that class can disappear from the MultiBit code base forever.

The Windows fix is already in bitcoinj master.

merged and pushed to github.

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.

A quick fix for windows:

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.

Just to not for everyone compiling Multibit form source:  Jim has updated his bitcoinj branch to: jim/encrypted-wallets-5

link here:
http://code.google.com/r/jimburton618-bitcoinj-coinbase-tx/source/browse?name=encrypted-wallets-5

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.

Just checked now as it seems to be on the website - do you have the page cached ?

ie hover over twitter link = https://blah blah

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

Mike,

I wanted to check something protobuf related with you.

I was going to drop from the wallet definition 'minor_version' which just leaves (initially):

  optional int32 major_version = 7;

As the qualifier 'major_' is then redundant am I right that I can define it:

  optional int32 version = 7;

?

i.e. recycle the same protobuf numeric identifier (that will be in the extant wallet files) but just call it something different in the Java code. I think this should be backwards compatible but just wanted to check with you.


The main reason I have not dropped version entirely is to detect 'wallets from the future'.
Also, I am going to make it an int in the Java code as per your comment, as the whole point of having it is for it to be ordinal. Going to leave it as an enum as you can localise it easily and more type safe.

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.

Links are OK but when you import resources, browsers will complain.

I think over time we'll phase out addresses for most users. They are convenient but have many problems. Exchanging payment request files/URLs is the way to go. Hopefully in the end most users will never see addresses/keys at all.

By the way I plan to reimplement your boomerang rule code in a different way.

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).

On multibit.org can you change http://platform.twitter.com/widgets.js to https://platform.twitter.com/widgets.js ?

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.

There is a new live release of MultiBit available at:

https://multibit.org


Version 0.4.18

Enhancements:
+ Issue 63 fixed (default fee of 1 BTC for comma decimal separator languages).
+ Removed splash screen (and help about) image as it was causing a Segmentation Fault on openjdk6 when viewed in 256 colors.
+ Fixed flickery first transaction row.
+ Fixed color of Transactions description column in RTL languages.

Scan of release checklist


This is primarily a localisation update with a few bug fixes and tidy ups.

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 think the right way to go for making MultiBit look sexier is probably judicious use of a few custom widgets and drawing styles. Having a white background with some tasteful artwork in the background can make a big difference to how an app looks. If you notice, most of the best looking web pages and web apps in the Bitcoin world  use non-standard button styles and the like, so they can more easily use color to distinguish things. There are probably libraries out there that can be used to spiff up Swing apps a bit, but even with standard widgets, just replacing a few things (like the tab selectors) with custom artwork would go a long way.