I am one of those happy users who never or rarely report anything.
I never lost a single satoshi or bitcoin using MultiBit.

I think it is again time to remember what a great software MultiBit is and to say:
Thank you! to all the developers behind the scenes and especially to Mike and Jim.

I think it really depends on the content of the message.
If the message just contains hex-like lists of addresses or the like without any meaningful statement, then the signer just prooves that he controls the private key to the address.
If the message contains a meaningful statement like e.g. a contract, the signature prooves that the owner of the public key approves of the message.

I want to point out, though, that it will still remain difficult to proove e.g. in court that the claimed owner of the public key is really the 'real' owner. If e.g. Jim's private key was stolen, the thief could sign messages instead of Jim. So Jim could claim in court that his private key was stolen and that somebody else (not Jim) signed the message with the stolen key. Regardless if a court or people will believe it, I just want to point out that prooving the ownership of the private keys is not the same as prooving your identity.

In some European countries the governments have started to incorporate the ability of electronic signatures into the identity cards. This is intended to identify yourself online in combination with a PIN. A thief would need to steal the ID card and get hold of the PIN. In the above example of Jim, as soon as Jim detects the theft, he will inform the ID card issuer to invalidate the electronic signature. Later in court he will be able to proove that he informed the issuer, freeing him of any responsibility of his stolen electronic signature. Failing to do so will make him liable in court, because he had the ability and the responsibility to inform the card issuer.
Since invalidating public keys is not possible with bitcoin, Jim will have a chance to claim in court that somebody else signed the message.

Hi Jim,

that is a very nice feature, Jim.

Please forgive me my noob questions:

How is the signature created?
Is it possible to derive from the signature the private keys?
Does a signed message cost something?
Who receives the signed message?
Is it send to the whole bitcoin network?
Or do I have to copy it to e.g. an email?

Could you come up with some use cases?

Is it possible to verify that a payment address is untampered by an attacker?
How would this work?

Is it possible to set up contracts?
How would this work?

Is it possible to proove that I control a specified address?
How would this work?

Is it possible to create multisignature addresses with this feature?

Hi Jim,

it sounds like this a possible way to loose bitcoins:

1) user opens/creates a new a wallet on USB pendrive
2) user removes USB pendrive with the MutliBit client still open while some background task is still writing to the USB pendrive
3) MutliBit notices that something went wrong during storage but does not find a storage medium.

Would it be a solution that MultiBit asks the user (e.g. in a dialog box) to provide a new storage place and filename in case of 3)?

Hi Jim,

you are right.
Since I am using automatic backups I tend to forget that many people do them manually and sometimes forget them.

Kind Regards,
fremoney458

Hi Jim,


What if BEFORE importing the wallet contained already more than one key?
In this case people would still experience that after importing keys the change is sent to an address outside their original 'somewhere' wallet.

To circumvent this, may I suggest that you send the change always to the LAST key of a wallet instead of the second key.

Of course people could import keys from multiple wallets or create new keys after the import, giving the same unwanted result as with the current solution (change to 1st key).

But there is an additional advantage to it:
Experienced users who want a 'fresh' address for the change of their next transaction can simply create a new address before spending.
For users who want to obfuscate the addresses they control, this could be helpful.
Because if the change is always sent to the same address this allows to easily track down which keys belong to the same wallet after a spend with change has been made.
On the other hand, if the change is sent always to a fresh address an analysis will not be able to link addresses which send change to the same address.

Hi Jim,

I am using MultiBit-0.5.8beta, and generally I am having a great experience using it.
Thank you for developing this awesome client.

I think I already mentioned the following in an earlier post, but want to get some update:

When creating a new wallet (or when starting the first installed version) MultiBit creates one address.
The wallet by default is unencrypted, so the private key for this first address in the wallet will be stored unencrypted in the filesystem.
At this time, malicious software on the computer would be able the seize the private key.
Therefore, I consider this private key and the corresponding public address to be insecure.
Even if later on you encrypt the wallet, the private key for this first address might already be compromised and could some months later be used by an attacker to seize the bitcoins stored at this address.

This behaviour I find especially troublesome due to the following reasons:
I. Change is sent back specifically to this first address. It can happen that large amounts are stored in this address due to this behaviour.
II. Now that MultiBit is the #1 recommended client on bitcoin.org for novice users (congratulations!), many people are using this client and more to come. This makes it a bigger target for attackers.

How do you want to close this tiny (but nonetheless existing) security hole?
Will there be a version without the first address generated by default?

Thanks again for all your efforts.

I just tried out v0.5.8beta
on a MacBook running OS X version 10.5.8,
connected to 1 bitcoind v0.8rc1 peer at riker.plan99.net (courtesy of Mike Hearn).
My internet connection is running at 100 Mbit/s.

One wallet with 20 addresses, reloading the whole blockchain (220867 blocks) from the genesis block took less than 11 minutes.
That equals 335 blocks/second.

Congratulations and a big THANK YOU to all bloom filter developers!

I like this project a lot.

I have a suggestion which might be a bit off-topic, maybe you can point me in a better direction where to address this.

Now that you have some exchange data happily being displayed in e.g. MultiBit, the next logical step will be to integrate a mechanism to buy and sell bitcoins.
I see the following possible approaches:
1. Integrating the APIs of one or more centralized exchanges like e.g. MtGox etc. Possibly the easiest and most useful approach today.
    Personally, I do not like these exchanges because these exchanges require a lot of trust in their honesty and integrity, technical skills to run the exchange and to secure it against attacks and because fiat money transfers to/from the exchanges usually take long or a lot of fees are involved. Also, there is a double risk involved: You can loose the deposited bitcoins AND you can loose the deposited fiat money.

2. Integrating Ripple-like mechanisms that already have been proposed elsewhere. The beauty is that it ends up in a p2p decentralized form of exchange. But there is still trust involved that all involved parties will be honest and settle their balances. Of course a rating system for every user can be included, but this involves setting up three p2p networks in parallel: Bitcoin, Ripple-like credit balances and a p2p trust rating system. It seems very high-end, but also very complex and therefore will take a long time to develop and to convince people to use it.

3. Integrating the API to a site like BitMarket.eu into the Bitcoin client. This is a mixture of 1 and 2. The real exchange is done on a person-to-person basis. All BitMarket.eu does in the first step is to bring together seller and buyer when certain criteria match: Agreed price and settlement method, basically. This could also be done in a p2p approach or using standardized IRC messages. In the second step BitMarket.eu acts as an escrow service where the offered bitcoins are only released to the buyer if the seller confirms that the price has been paid. But there is still trust needed in the escrow functionality, if a centralized site like BitMarket.eu is used.

In order to get rid of a centralized escrow service from 3, I suggest to set up a p2p escrow functionality directly as an extension to the client. This leads to a fourth approach:

4. Integrating the mechanisms to bring together buyers and sellers if prices and settlement method match (maybe standardized IRC messages are sufficient) AND THEN to use multisignature transactions as an escrow service within the p2p client exchange network. It basically means the same user experience as in BitMarket.eu, but all completely within the Bitcoin client. So there is no need for a centralized exchange and no need to trust a centralized institution as escrow.

Do you think this is feasible? Do you know a better place where to post this?

Very nice plan!
I am missing multi-signature transactions on your list, though. Any plans to support these in bitcoinj or MultiBit?

Hi Jim,

yes, I have MultiBit set to German.

I looked things up more in detail:

The multibit.properties showed sendFee=1.
After changing in MultiBit to '0,001' BTC MultiBit used the correct fee during sending.
After quitting MultiBit and restarting it, it showed the correct fee on the screen: '0,001' BTC.
The multibit.properties showed sendFee=0.001.

So everything is like expected.

Maybe it was just a historic setting that now turned up when I seriously spent my first coins.
I will have a look at it when I update the next time to a newer MultiBit version.

On another note: I investigated the two rapid succession of 'send' transactions more in detail and found that the second transaction was actually done by spending the change from the first transaction. This was done within seconds after the first transaction.
So your boomerang rule worked out fine. 

I forgot to mention that in the latest beta version, I noticed that the transaction fee was set by default to 1 BTC.
I think this is way to high and can be really disgusting for novice users.

I am not sure if it is part of the binary download version.
If it is, I suggest you reduce the amount and maybe even add it as a check to your release checklist.

Hi Jim,

Version 0.5.7beta (Encrypted wallets) downloaded and sent some coins to BitMarket.eu, a free bitcoin exchange market who now needs a bit financial help.

I sent coins two times in rapid succession, I did not notice any unexpected restrictions due to change problems.
I can not tell for sure if it was due to the boomerang rule though, because I have about 20 addresses in my wallet and MultiBit used different addresses to send from.
Anyway, I just wanted to tell you that the whole sending experience was very smooth and fast.

Great work!

Hi Jim,

just tried it out. Works fine on my Mac OS X 10.5.8, great work!

Small finding:
I found that in the transactions panel the BTC decimal alignment gives a weird result if you have amounts with decimals and without decimals. It seems that the decimal separator shifts amounts WITH decimal places a bit to the LEFT. The result is that the digits from amounts WITH decimals are not aligned with the corresponding digits of amounts WITHOUT decimals.

Thank you for this great client!

Hi Jim,

the new currency conversion features are absolutely awesome!

I also like very much that MultiBit now shows the transaction volume in one column instead of two, it saves a lot of screen space.

One proposal for the currency conversion:
The exchanges always produce several prices, especially ask and bid rate.
Some users might want that incoming bitcoins are shown with the 'bid' exchange rate and outgoing bitcoins with the 'ask' exchange rate.
Others might want the exact opposite behaviour or that the latest price shall be used.
This can be very user specific and might even be different depending on the use case, e.g. if the user in one case acts as a local exchanger and in another use case acts as a simple consumer.

Here are my suggestions:
1. The user should be able to set the automatic currency conversion behaviour of MultiBit individually per wallet. This way users can handle different use cases by using different wallets.
2. Automatic currency conversion to BTC prior to sending BTC: The user should be able to specify in the send dialog which price to use (ask, bid, latest). The default rate should be used according to 1.
3. Automatic currency conversion to BTC prior to requesting BTC (=creation of a new address): Same like 2.
4. Automatic currency conversion behaviour in the transactions pane should be fixed per wallet according to 1.

Thinking about it, it might as well be a very bad idea due to the complexity for the user. It might create more trouble than it is worth...
Anyhow, I wanted to mention it.

Cheers,
freemoney458

I suggest

Tesaurox,
Tesaubox,
Tesaunox.

They are all mixtures of the Greek 'Thesauros'=treasure house, the Spanish 'Tesoro'=treasure coming from the same source, and the English word 'Box'. The last one I created because it has a similar sound like 'Knox' from 'Fort Knox' for all those which are more familiar with modern than ancient history.

Have fun when picking your name!
Edit: Please also feel free to use it as a starting point for further modification, I am not interested in the bounty. This should be fun!

Hi Jim,

sorry to find another small strange behaviour:

3) When changing the user language, and afterwards changing from the preferences screen to any other screen, e.g. transactions screen, the language of the elements *inside* of this screen is still in the old language.
The change of the language only takes full effect after exiting and restarting MultiBit.

BTW: I agree that right click menus are not the best way on tablets or cell phones   .

Edit: The reordering of columns by dragging the column header is cool  ! I didn't notice it. Glad you mentioned it.

Hi Jim,

I just noted the following:

1) When sorting entries in the transaction screen by the amount, the sorting algorithm uses alphabetical ordering instead of numerical ordering.

2) The user is able to make columns in the transaction screen wider and can choose a column to sort the entries, but currently these settings are not stored.

I guess fixing this will be a low priority.

Hi Jim,

fair enough that you consider it.

I fully understand that keeping MultiBit simple to use is becoming a challenge since the userbase grows and with it the demands.
Maybe you can make some of the advanced features accessible through 'right click context sensitive menus' like in the transaction screen.

Keep up the great work.

Hi Jim,


I can understand the differences in usage and that users will have varying preferences even when talking about a single user.

However: If MultiBit would save the amount then users will still be able to choose how to use the amount field.
If somebody does not like to see past amounts for a specific address then he can leave the field empty from the beginning (at least for receiving addresses) or delete the amount later.