Release information

[jim618]

There is a new live MultiBit release at:

https://multibit.org


Version 0.4.20

Features:
+ Support for more currency exchanges. (XChange 0.4.0).
+ You can move up and down wallets with the Shift-ArrowUp and Shift-ArrowDown keys.

UI changes:
+ More contrast between the active wallet and the others.
+ Less flicky when changing language, font and look-and-feel.
+ Improved font display in dialogs, help, tooltips.

Bug fixes:
+ Fixed bug on display of fiat amount in Send/ Request when changing languages.
+ Fix for 'Transaction cannot be cast to Comparable' bug on wallet reorgs.


Release checklist

[1714100042]

1714100042

[1714100042]

1714100042

[1714100042]

1714100042

[1714100042]

1714100042

[jim618]

There is a new test MultiBit release at:

https://multibit.org/releases/multibit-0.5.8beta


Version 0.5.8beta

Bitcoinj v0.7 features:
+ Bloom filters now active to speed up blockchain sync (when talking to bitcoind v0.8rc1 nodes or later).
+ You can now specify particular peers to connect to with the 'peers' property in multibit.properties. (Use a comma separated list).
+ Fix for zero confirmation transaction vulnerability identified by Retep.

XChange 1.4.0 features:
+ More exchanges supported for currency lookup: MtGox, Bitstamp, BTC-E, CampBX, VirtEx.

UI enhancements:
+ You can use Shift-ArrowUp and Shift-ArrowDown to move between wallets when the Wallets panel is selected.
+ Wallet icon now highlighted when wallet is selected, more contrast between selected and unselected.
+ Display less flicky when changing languages, fonts and look-and-feel.
+ User chosen font now set properly in dialogs and Help screens.

General:
+ No longer opens in 'local mode' - it picks up your other MultiBit wallets.
+ Removed cacheManager code - no longer supported
+ Backward compatible wallet changes (description added, minor version dropped).
+ Serialised wallets now no longer always load - you may have to use an older version of MultiBit and migrate them to protobuf format.
+ Refactoring of encryption code in response to review comments.
+ Fix for 'Transaction cannot be cast to Comparable' bug on wallet reorgs.

Release checklist


To get the benefit of bloom filters you currently need to connect to a bitcoind v0.8rc1 node.
There is one at riker.plan99.net (courtesy of Mike Hearn).

If you are running a bitcoind v0.8rc1 node on an external IP address and don't mind people connecting, please post your IP address here so that people can try out the bloom filters.  Thanks.

[jim618]

There is a new test release of MultiBit available at:

https://multibit.org/releases/multibit-0.5.8beta.spendpolicy/

Version 0.5.8beta.spendpolicy

This version is very similar to v0.5.8beta but has Mike Hearn's branch called 'spendpolicy' merged in.
This gives the same functionality as the 'boomerang rule' code where your change is spendable once it is seen by 2 or more peers. It is implemented in bitcoinj rather than the MultiBit code base and is implemented in a more general way.

From the MultiBit user's point of view the only difference is that when you spend from one wallet to another (of your own wallets) it is immediately spendable now.   This code was a 'stretch goal' for inclusion into bitcoin-v0.7 so if it tests ok it should go in.

Release checklist

[slush]

If you are running a bitcoind v0.8rc1 node on an external IP address and don't mind people connecting, please post your IP address here so that people can try out the bloom filters. 

My node is 84.42.190.168

[jim618]

Cheers Slush.

This means that if you put into your multibit.properties:

peers=riker.plan99.net,84.42.190.168

You will connect to BOTH bloom filter nodes - this has the advantage that your change is spendable straight away (the only problem with connecting to a single node).

[jim618]

There is a new live MultiBit release at:

https://multibit.org


Version 0.4.21

Features
+ Bloom filters now active to speed up blockchain sync (when talking to bitcoind v0.8 nodes)
+ You can now specify particular peers to connect to with the 'peers' property in multibit.properties. (Use a comma separated list).
+ Upgrade to bitcoinj v0.7 - numerous changes under the hood e.g. quicker network connect, sends between wallets you can spend immediately.
   
UI Changes
+ Currencies in the Preferences tab now have a full description in addition to the currency code

Release info
https://multibit.org/test/releaseCheckList-0.4.21.jpg


Bloom filter support
This is the release with the bloom filter support in. When you connect to a bitcoind v0.8 node you sync speeds should be a lot quicker.

At the moment there are just over 10% of the nodes upgraded. MultiBit connects to 4 peers so the chances of getting at least one v0.8 node is:

1 - (1 - 0.1)^4 = 34%

When it goes up to 15% of nodes your chance are 48% and at 20% of nodes it is 60%. That will probably take a week or two for that many nodes to update.

Thanks
Thanks to Mike Hearn and Matt Corralo who coded up the bloom filter work, and Andreas Schildbach for his detailed testing of the early versions.

[World]

wow ,synchronising with network take only few second thx

[jim618]

Yeah - it's a big improvement especially if you are on a slow network (the sheer size of the blocks was starting to slow my syncs down)

[jim618]

There is a new live MultiBit release at:

https://multibit.org


Version 0.4.22

Features:
+ Addition of OpenExchangeRates.org as an exchange. Provides over 150 currencies for currency conversion. (Needs free sign up).
+ Charts can be saved (right click on the chart: "Save as").
+ Updated to Bitcoinj 0.7.1, XChart 2.0.0, XChange 1.5.0.
+ Reset blockchain and transactions default "replay from" date now goes back 2 days.
+ Simplified buttons in wallet list.

Bug fixes:
+ Fixed appearance of blank request screen.
+ Menu tooltips on Macs shown properly.

Release checklist

The help for the OpenExchangeRates sign up is now available from your MultiBit "Help | Help Contents" menu option. It is the help page "Currency ticker" which shows:

https://multibit.org/help_ticker.html

[jim618]

There is a new live MultiBit release at:

https://multibit.org


Version 0.4.23

+ Fix for incoming transactions not seen sometimes.
+ Updated to bitcoinj 0.7.3.
+ Notifies user when a new version of MultiBit is available.
+ Tidied up UI when switching "look and feels".
+ Change is now sent to the second key in a wallet if present (this helps people who have imported a blockchain.info backup).
+ More logging.


Release checklist

[christop]

Nice. I'll give Multibit another try. I played with it a week or so ago but a couple major bugs turned me off. I'll see if those bugs are still present in the latest version, and if they are I'll report them officially this time.

Here are the bugs I found in the older release and will be testing in a newer release:

- Importing a second private key into a wallet causes Multibit to hang
- Sometimes syncing hangs (probably due to first problem)
- One of my transactions got accounted to the wrong address
- Cannot set tx fee to less than (I believe) 0.0005

[Mike Hearn]

Is there a reason you're importing keys instead of just sending money between wallets using regular transactions? I mean, it should work, but sharing keys between different wallets opens up a variety of ways things can go wrong. It's really not meant to work that way.

[christop]

Is there a reason you're importing keys instead of just sending money between wallets using regular transactions? I mean, it should work, but sharing keys between different wallets opens up a variety of ways things can go wrong. It's really not meant to work that way.

So far I've only received money into all of the keys that I've imported, so there shouldn't be a problem. Multibit should record money coming in regardless of where the key was originally created, such as in Bitcoin-qt, with vanitygen, or with any other private key generator. Even sending money with one of those keys from another client shouldn't cause any issues, as any client worth its salt would record those transactions and deduct the amount from the respective wallet(s) correctly.

I can understand that (apparent) issues might be caused by Bitcoin-qt's handling of hidden private keys (for returning change, for example), but that is not the case here as I have not made any transactions with any Bitcoin client with those keys. I've also verified transaction amounts on Blockexplorer and Blockchain to see how much has been sent to my addresses, and it simply mismatches what Multibit reported.

Besides, if sharing keys exposes bugs in the software, then it's a good way to shake out those bugs so they can be fixed.

Lastly, I want to share keys between clients because I want to have access to my Bitcoins on multiple computers--one at home and one at work. I'm also in the early stages of learning about Bitcoin and figuring out which clients are worth using by seeing how they handle transactions. Only Multibit has incorrectly accounted for received coins so far.

[jim618]

Can you see if you have problems with receiving transactions with the 0.4.23 code as there is a bug fix in for that ?

There are a few subtleties with sharing private keys.
For instance, currently the user is not prevented from sending transactions whilst the block chain is being synced. This only works in general if keys are not shared (as there could be transactions in later blocks from somewhere else that have spends in).

If sharing private keys is relatively common (which it probably is) then I will have to add in that you cannot do a spend until the blockchain is synced. With bloom filters that is not too much of a hindrance but is still a restriction.

On some of your other points:
+ yes there is a minimum fee by design to reduce the poor user experience of transactions with zero fees taking ages and ages to confirm.
+ if you have a transaction where bitcoin is sent to more than one of your addresses MultiBit might report that it is sent to one that you did not expect - the transaction is the same and the amount is the same. If you do a right click on the transaction and see the details you can see the raw transaction which explains it.

[Mike Hearn]

Yes, exactly, it's not safe to do this yet because there are cases in which you might accidentally create double spends. As far as I know there are currently no clients that are guaranteed to do this right (except for the ones where the whole wallet is hosted by some remote server).

I don't really know what you mean by "a transaction got accounted to the wrong address". Could you be more specific?

[christop]

I'll test 0.4.23 sometime in the next few days (sorry, I'm kind of busy this week).

I don't really know what you mean by "a transaction got accounted to the wrong address". Could you be more specific?

Here's a transaction that Multibit recorded:
12 Mar 2013 05:29
0.00098 BTC
Received with 1EDvr5PCtn5CikTBxqkEYg3A72K5vUAjHz
Transaction: 1f1e3ffe3a091bde54181f43aa24bf182444691f190edf4bde316b51361217ea

However, if you look at the details of that transaction on blockexplorer.com or blockchain.info, you'll see that only 0.0002 BTC was sent to that address. I have another address (17Z63hLi2ox4fCMhDqVJrLTJiXVcBMJpMo) that just happened to receive 0.00078 BTC in the same transaction. Both of these outputs add up to 0.00098 BTC. I suspect that Multibit is getting tripped up by the fact that both addresses are receiving money in the same Bitcoin transaction.

[Mike Hearn]

It's not really the "wrong" address, is it? I guess you mean you were expecting to see both addresses there instead of just the first. All the money did actually turn up.

This is basically a MultiBit UI issue, it should probably try to show all matching addresses/labels, though that case is going to be rare for most transactions.

[christop]

It's not really the "wrong" address, is it? I guess you mean you were expecting to see both addresses there instead of just the first. All the money did actually turn up.

I could argue that it is the wrong address because it's not the right address. But you are correct that I mean I was expecting to see both addresses listed, perhaps in two separate "transactions" in the UI. And the address that it showed as receiving the full amount was actually the second of my two addresses in the transaction. The 1EDvr address was output 309, while the 17Z63 address was output 195.

It's good to see that it's only a UI issue, though.

[jim618]

There is a new test MultiBit release at:

https://multibit.org/releases


Version 0.5.9-SNAPSHOT

Features:
+ I18n update.
+ Update to bitcoinj 0.8-SNAPSHOT
+ added 'Close Wallet'
+ wallets now resync automatically when opened
+ added better sync control on import and reset blockchain
+ changed blockstore to SPVBlockStore - smaller download
+ uses checkpoints file (12K) rather than block headers file (about 20MB).
+ changed 'Reset blockchain and transactions' suggested replay date to 2 days ago.
+ reduced default fee to 0.0005 BTC

Bug fixes:
+ fix for unparseable fee amount
+ apostrophes now appear in French and Italian translations properly


Release checklist


This (after an official bitcoinj v0.8 release, more testing, a release candidate, more testing and then another release) will become the first live release with encrypted wallets in it.

[jim618]

The encrypted wallets release candidate is now available at:

https://multibit.org/releases/multibit-0.5.9rc1/


Version 0.5.9rc1

Features:
+ Upgrade to bitcoinj v0.8
+ Delete Wallet not shown by default, challenge question added (see configuration.txt).
+ Romanian added as target language.
+ Mac app is now signed with a "James Burton" developer id.
+ Fix for Mac retina display showing fuzzy text.
+ Twisty and callout panel in the wallet panels have been removed.


Release checklist


This is the MultiBit release candidate for the encrypted wallets.
Please try it out.

I plan to keep it on the website for a week and see what feedback/ bug reports I get.
If people generally give it the thumbs up then I will release it as live code for the general user.

Whilst people are testing it I will be tidying up the help and unit tests. Gary and I are also working on a multibit.org website re-vamp.
I have also bought an 'identity verified' certificate to sign the Windows exe. There will be a delay in getting this as it involves bits of paper with authorisation codes being transported across Europe. The version 0.5.9 will probably get released without this.