Release information

[jim618]

There is a new live MultiBit release at:

https://multibit.org


Version 0.5.9 (Encrypted wallets release)

+ You can now password protect your wallets.

+ Version number removed from Mac app name.
+ Updated help files.
+ Fixed bug on opening wallet that is already open.
+ Fixed ticker restart bug.


Release checklist

[jim618]

There is a new live MultiBit release at:

https://multibit.org


Version 0.5.10

Changes:
+ Fixed issue 116 - could not import blockchain.info backups.
+ Fixed issue 117 - fee was too high.
+ Fixed issue 121 - MtGox ticker information not showing.
+ Fixed issue 125 - improved overzealous syncing of wallet(s).
+ Fixed issue 137 - Import / Export filechooser nomenclature.
+ Fixed issue 140 - use installed checkpoints file if newer.
+ Fixed issue 141 - bump to XChange 1.7.0, XChart 2.2.0.


Release checklist

This is primarily a bug fix release, together with updates of the XChange and XChart libraries.

[da2ce7]

There is a new live MultiBit release at:

https://multibit.org
Version 0.5.10

Since this release contains code that I have written.
I have done only casual checking, other than verifying Jim's pgp signatures for the files.

Code:

SHA256(multibit-0.5.10-linux.jar)= 4b9593444abe96c8e777bddc85227b26685c2fb6dd3ce7a6db856d61a78e059a
SHA256(multibit-0.5.10-windows.exe)= 15817c0b10cd60e39dcc8aee31db0b03b5a2aafd8337578e3f381bad5c0e4937
SHA256(multibit-0.5.10.dmg)= 133b504295be167ce41476cb2d6c21b219fbe786fa97d08ce2c6e5dee30bafbe
SHA256(multibit-exe.jar)= ce4c8248fda31a466c5c7af23537f324ee162fef63328cc79a0a08bfefc9f91e
SHA256(multibit.exe)= 5123099005ebb9bfbd5329a9867cf3da1e498eea50fb341e60e6f4d5ac8cc2fd

Code:

-----BEGIN PGP MESSAGE-----
Version: GnuPG v2.0.19 (MingW32)

owF1kT1olEEQhr+YKPFEML1F7ExxH7s7+4sIKgi2Yi/M7MyG83IRTUIOFa4RVLAQ
bBXxBwRRtLlaLBRRwUIIaGflKdhbCHEDsQppZ+B5Zt73zsHpZnZu5sFhBeMfG1Mf
38xTc/bJs1Pnzpw0zh8drC2t9qi32lWta7XqLvWW14btBby8cHzeUnIJrLVIknyO
EkIg5hydMYGM99FlU8gzQ5aAnik6z15jiKJcws4ujvXeMl9cX2llKNWiXdQhK9Iq
s1cCiXOOKAKaSZECcmgQC0eA4CoZCkRNyC4rsQnCLpaWB4tbdKgAZU1yJNqHLFbb
4DMZ9tloMjoVkhB9wRRYxSwme3Fc9YqwrnbQ69Hb8VRWjsbGwggarffZ5YDFgINQ
wFipQlOkeAATcw4JFapIdZJTSXoHejsPpw2olJRyQpSoEDswCVOs1xdg1PXrKIJO
FQKrpWbmi2WHuUpM4c7N8zPN3Gyzb++erZ6bzv5D/9t/1Z9qnh84vXL7yKfR5F7/
xte/7eTX+OXjp+9fbCyO375W10/cbzb7I79wN936M3x0dfPb75/Hrj280v3wzo+m
B4PJl0vfP/8D
=dIYL
-----END PGP MESSAGE-----

Edit:  Jim, can you please push your master branch, I would like to see if it is possible for me to create identical builds.

[jim618]

Hi Cameron,

I have pushed the MultiBit master branch but noticed I made a slight mistake in build procedure.
I built the 0.5.10 artifacts whilst on the release-0.5.10 branch, not master.
You probably want to checkout that branch and see if you can reproduce the artifacts.

Jim

[jim618]

-----BEGIN BITCOIN SIGNED MESSAGE-----
There is a new release of MultiBit at:
https://multibit.org

Version 0.5.11

Changes
+ Implemented issue 96 - Sign and Verify message.

Release checklist:
https://multibit.org/test/releaseCheckList-0.5.11.jpg


Bitcoin signing:
This message text (starting with "There is a new release" and ending with "Jim")
is Bitcoin signed with the https://multibit.org donation address.


SHA256 hashes for files:
a6bcffea1fc04d5ccbd8d240854d62d7ae425802010bdbd3ed9335907246a922  multibit-0.5.11-linux.jar
111096d1db1952d623512a970057aa28f3951769c627fb49c2d29b6b263e60bb  multibit-0.5.11-linux.jar.asc
90a11dfe000311b6e3051c00b31befdc48dc75415254df4ab45f0fc464b3cd23  multibit-0.5.11-windows.exe
20088187c694feb9ed12aab20fa3019852e6a32bdcbf8d393c291bdb2697d9aa  multibit-0.5.11-windows.exe.asc
8446d10a78642f1fe2dc3db97f931eb2f2adc0235798a323ecd6f0e007c63746  multibit-0.5.11.dmg
b4f0d30c2e7f9a16d099f528c8c5a643ba793e2054def09908a38531a0f3af69  multibit-0.5.11.dmg.asc
b335678911efc743bf8e1149fd54a5c8bfc2a9105d6c06f1e51df70f5112df7a  multibit-exe.jar
f193ca928e9df520b55d1765ffb9743c5bdb9cc1501079895f321d5931ea8dea  multibit-exe.jar.asc
bee1a14a97268455d41303bc09e51a097ad028a7cdd213e6a4072f4c6bd815ed  multibit.exe
29d14ddb98337a52a63046ec0d3cb0574d43a8f0e9020ee00306910aafe5432a  multibit.exe.asc


PGP signing:
You can verify the PGP signatures by installing gpg and importing the key id 0x79F7C572
from http://pgp.mit.edu. To verify, say, multibit.exe type:
gpg --verify multibit.exe.asc

The files are signed with the subkey with id 0x23F7FB7B

Jim
-----BEGIN BITCOIN SIGNATURE-----
Version: Bitcoin-qt (1.0)
Address: 1AhN6rPdrMuKBGFDKR1k9A8SCLYaNgXhty

HCHgnCEBrhm9DoywH6qyRkiLcdkwlI388/uHZ2e2tDBwu5HkrMFrCAoXN+FU4FvOueAxM/XYGoaDvYVeI/0tXkw=
-----END BITCOIN SIGNATURE-----

[jim618]

-----BEGIN BITCOIN SIGNED MESSAGE-----
There is a new release of MultiBit at:
https://multibit.org

Version 0.5.12

Changes
+ Updated to bitcoinj v0.9
+ Fees are now calculated automatically. Code by Matt Corallo
+ The size of the transaction appears on the transactions detail dialog
+ Fixed issues 150, 165 - Automatically recreates BlockStore if there are problems loading it
+ Fixed issue 155 - Version.txt retrieval error on Java 7
+ Fixed issue 156 - Verify message available when wallet is syncing

Release checklist:
https://multibit.org/test/releaseCheckList-0.5.12.jpg


Bitcoin signing:
This message text (starting with "There is a new release" and ending with "Jim")
is Bitcoin signed with the https://multibit.org donation address.


SHA256 hashes for files:
8ceefa0edafbf297c9276b6cb893e808a36646e915b5c671ab884ac5c431f83e  multibit-0.5.12-linux.jar
38347714a510a07f47b81d218da63ea83aebb6de4eb36952ae90e970b25c7480  multibit-0.5.12-linux.jar.asc
248e13824a422266ebf6f13252863aaac3db4658cda120d091468fd493817a62  multibit-0.5.12-windows.exe
290504e880984a93cf91d5b944fe0527f039b744e9a0ae9ffff23a12531d81da  multibit-0.5.12-windows.exe.asc
947f73aa519a14f5bebda1f94a9c51c57bf5713a61f706def8cd4f8c189eddd8  multibit-0.5.12.dmg
4e5d0be0ad4e91a0f7ee716cdd312de861ad5de153a09671f4c1eefb60175766  multibit-0.5.12.dmg.asc
f8e1523023a54a7af390138373991de305844bb339c036439f9055d0ef23db26  multibit-exe.jar
ee6f5125d1faf7fa939b91d991eb0001de515b6b3fa6bcd2370411122d633fbe  multibit-exe.jar.asc
b2a953ba49dcae2f6f9a731663e3e81b6276956a701176ea5c8f8a862d7f9291  multibit.exe
10cced6434441462ac8388d9071a92fec2c95653ac821b22a7658b4528b1cab9  multibit.exe.asc


PGP signing:
You can verify the PGP signatures by installing gpg and importing the key id 0x79F7C572
from http://pgp.mit.edu. The files are signed with the subkey with id 0x23F7FB7B.

Jim
-----BEGIN BITCOIN SIGNATURE-----
Version: Bitcoin-qt (1.0)
Address: 1AhN6rPdrMuKBGFDKR1k9A8SCLYaNgXhty

GyNn9yWgY0s5BKZLu3PxRtt9BaGL0ATVHVAQKlEo0fd9c/7jKzqTwCu3k/y/JagsLOT5T+XuAhtn6W+acrM5yq4=
-----END BITCOIN SIGNATURE-----

[Chooseusername]

+ Fees are now calculated automatically. Code by Matt Corallo

So, where do I turn off this "feature"? If I want to set it manually?

[jim618]

At the moment you cannot tweak the calculated fees.
They are calculated as pretty much the minimum bitcoin-QT will accept.

Currently, as other software has not adjusted their fees downwards, when the network is busy you can get bumped to later blocks as the fee is a bit on the low side. I'm going to see how this develops - the fees people set create a feedback loop as to which transactions get in which block. (If you have a look at some of the posts I have put in the other alt clients threads this is explained more).

It might be necessary to add in something like a slider so that you can increase the fees above the minimum but I am hoping not to have to do that. Fees aren't something that a new user should have to worry about as it just adds to the learning curve for Bitcoin.

Edit: Also, to get the 'correct' fee is quite involved - have a look at the class FeeCalculation in this class:
http://code.google.com/r/jimburton618-bitcoinj-coinbase-tx/source/browse/core/src/main/java/com/google/bitcoin/core/Wallet.java?name=bcj-master-mb-alice

(starts line 2982).

[jim618]

@Chooseusername
I am interested in why exactly you want to set a specific fee. Is the calculated one causing you problems ?

[Mike Hearn]

If people's transactions are getting bumped we should ask miners to increase their soft block size limits again.

[jim618]

Hi Mike,

I think what's happening is:

1) Currently the 'general' fee for a < 1KB tx in BitcoinLand is 0.0005 BTC. This is my estimate from having a look at the tx in the live stream on the blockchain.info home page.
2) MultiBit 0.5.12, Andreas's Wallet v3.0.9 and Bitcoin-QT 0.8.2/3 have moved to lower fees of 0.0001 BTC for the first KB.
3) Generally tx seem to get 'serviced' in order of creation but when there is a big gap between blocks the unconfirmed tx start piling up.
4) Miners seem to be using a soft limit of 250 KB so they naturally put in the juiciest tx into their block. They clear about 600 of the tx from the unconfirmed pool for each block.

If the next block also takes an above average time to solve then the low-fee-tx can continue to get bumped by juicier tx that appear.

I have suggested to the other alt client devs that they have a *great* opportunity to save their users cash and drop their calculated fees to match the Bitcoin-QT fees. It is a bit of a Prisoner's Dilemma - I think Electrum tried to drop their fees to 0.0001 BTC / KB about a month ago but had to increase them again as no-one else did.


I think if/once most clients match the Bitcoin-QT fee structures the current soft limit on blocks will be sufficient - I think the miners are processing same-fee tx by age first (which effectively makes it first-transmitted-first-served).

It's a pretty interesting dynamic system the whole area of fees I must admit.

[Mike Hearn]

Yes it's time to find the miners who are still doing that and ask them to reconsider.

[Chooseusername]

@Chooseusername
I am interested in why exactly you want to set a specific fee. Is the calculated one causing you problems ?

To make my transactions being processed fast in cause of %whatever_happened%, for example. And because it's my money and I want to control it by myself, not by algorythm. And at last because I can. So, I'll stick with 0.5.11, I guess. It's your program of course, and you choose how to develop it, but why make slider, why not just field pre-filled with automatically calculated fee which I can change? Why you disable me to change fees? I'm not a new user, I can worry about fees by myself.

[HostFat]

why not just field pre-filled with automatically calculated fee which I can change?

I agree with this.
You can even add an advanced option to enable this possibility if you want, but I think that it's really needed.
I also want to be able to chose/change the fee.

[jim618]

@Chooseusername
I am interested in why exactly you want to set a specific fee. Is the calculated one causing you problems ?

To make my transactions being processed fast in cause of %whatever_happened%, for example. And because it's my money and I want to control it by myself, not by algorythm. And at last because I can. So, I'll stick with 0.5.11, I guess. It's your program of course, and you choose how to develop it, but why make slider, why not just field pre-filled with automatically calculated fee which I can change? Why you disable me to change fees? I'm not a new user, I can worry about fees by myself.

I appreciate what you are saying but it is just more complicated than that.

Say you increase the calculated fee. That needs paying for so you may need to bring in another tx input to spend. So now the tx is bigger. Maybe it needs MORE fee because it has slipped over a 1000 byte limit. So you try adding MORE tx inputs. But if you only have dust remaining in your wallet you can be worse off in that the tx inputs you just added are worth less than the extra fee you need to pay for adding them. You had a good tx with the smaller fee but cannot find a tx providing the increased fee.

Or maybe the new change amount you've created is under the new limit for small tx outputs - 5430 is it or is it 5340 satoshi ? Best write it down as you'll need to manually check that after you made the change to your fee - that small amount should get added to your fee to eliminate the small output. So you've eliminated a tx output so now the tx is smaller. So now you can possibly have a smaller fee to get the same effect as you had before you changed the fee. Do you want the option to rechange the fee a second time ?

Honestly have a look at the code I pointed to about calculating a fee.
Of course it is your bitcoin but it is now impractical to work out the right fee manually.

A 'bad' fee means your tx either cannot be constructed (immediate fail), does not propagate (obviously bad but worse because then any change won't be spendable - very unpopular) or your tx takes ages to confirm (equally unpopular).

Sticking on 0.5.11 means you may create tx that don't propagate or take ages to confirm. It is your choice of course but my aim is to get people's transactions out in the network, propagated and confirmed as painlessly as possible for everyone.

[Chooseusername]

Of course it is your bitcoin but it is now impractical to work out the right fee manually.

Sticking on 0.5.11 means you may create tx that don't propagate or take ages to confirm. It is your choice of course but my aim is to get people's transactions out in the network, propagated and confirmed as painlessly as possible for everyone.

Well, you're right. I'm sorry for my ignorance and thank you for detailed explanation.

[jim618]

Hi Chooseusername, HostFat,

No problem at all - I thought I would reply in detail as the technical details aren't at all obvious. Fees have become a little complicated and I expect they will change again in the future.

Bitcoin is an experiment after all !

I think you are right that there is still something missing though in that the user DOES want to change the fee sometimes according to the priority of the transaction. Simply having a computed value and not being able to change it does not feel right.

For instance if I am moving money around my own wallets/ amoungst friends it does not matter if it takes a little longer. But if I am in a coffee shop sending money to someone (eg localbitcoins) then I would probably increase the fees paid so that it will (almost certainly) get in the next block as we both save time. Or the payment might be important/ urgent for some other reason.


One of the parameters in the feesolver is "fee per kilobyte of transaction" so that seems like a good candidate for tweaking. It is hardwired at 0.001 BTC / KB at the moment but it might be worth making this something the user can set in the Preferences. Of course it is a little more work but that might be the way to go.

That way users still have control over what they want to set (tx urgency/ priority) but don't have to worry about all the fee rules.

[gotpetum]

@Chooseusername
I am interested in why exactly you want to set a specific fee. Is the calculated one causing you problems ?

To make my transactions being processed fast in cause of %whatever_happened%, for example. And because it's my money and I want to control it by myself, not by algorythm. And at last because I can. So, I'll stick with 0.5.11, I guess. It's your program of course, and you choose how to develop it, but why make slider, why not just field pre-filled with automatically calculated fee which I can change? Why you disable me to change fees? I'm not a new user, I can worry about fees by myself.

I appreciate what you are saying but it is just more complicated than that.

Say you increase the calculated fee. That needs paying for so you may need to bring in another tx input to spend. So now the tx is bigger. Maybe it needs MORE fee because it has slipped over a 1000 byte limit. So you try adding MORE tx inputs. But if you only have dust remaining in your wallet you can be worse off in that the tx inputs you just added are worth less than the extra fee you need to pay for adding them. You had a good tx with the smaller fee but cannot find a tx providing the increased fee.

Or maybe the new change amount you've created is under the new limit for small tx outputs - 5430 is it or is it 5340 satoshi ? Best write it down as you'll need to manually check that after you made the change to your fee - that small amount should get added to your fee to eliminate the small output. So you've eliminated a tx output so now the tx is smaller. So now you can possibly have a smaller fee to get the same effect as you had before you changed the fee. Do you want the option to rechange the fee a second time ?

Honestly have a look at the code I pointed to about calculating a fee.
Of course it is your bitcoin but it is now impractical to work out the right fee manually.

A 'bad' fee means your tx either cannot be constructed (immediate fail), does not propagate (obviously bad but worse because then any change won't be spendable - very unpopular) or your tx takes ages to confirm (equally unpopular).

Sticking on 0.5.11 means you may create tx that don't propagate or take ages to confirm. It is your choice of course but my aim is to get people's transactions out in the network, propagated and confirmed as painlessly as possible for everyone.

Thanks for working on principled solutions that will elegantly handle the edge cases, jim618 :-)

In the meanwhile...

Fees    0.0001 BTC
Estimated BTC Transacted    0.781 BTC
Estimated Confirmation Time    12 hours (queue position 3002)

:-P

[jim618]

Hi gotpetum,

The blockchain.info estimates can be a bit larger than things actually take.
Would be interested to see how much time/ how many blocks your tx actually takes for its first confirmation.

[jim618]

I just checked on blockchain.info.
As I type there are about 2500 transactions 'hanging around' unconfirmed.

The miners seem to cap their blocks at just under 250KB, clearing  about 500 transactions each block.

Network is busy, transactions stack up, miners are not clearing them by putting them in blocks