MultiBit

[SRoulette]

Hello, we would like to say thank you for your excellent alternative wallet.

We have been using your client extensively in our testing since discovering bitcoin uri's and then your incredible wallet.
The network synchronization speed, support of uri's and multi wallet support are simply fantastic.

We should not ask for more, .... but

• Option to display the full 8 decimal places in the main transaction window.
• Option for Sound notifications on new transfers (a feature we quite like on the android bitcoin wallet and blockchain.info)
• Option for tool tip of incoming transactions.

Keep up the great work.

[1713408623]

1713408623

[1713408623]

1713408623

[1713408623]

1713408623

[1713408623]

1713408623

[1713408623]

1713408623

[1713408623]

1713408623

[jim618]

Hi SRoulette,

Thanks for your feedback.

The display of the full 8 decimal places is going into the next release (4.11) as it is the Bitcoin norm and the 'Satoshi digits' are starting to be used for various things now.

Sound I will have a think about - certainly doable.

RE: the tooltips for incoming transactions - do you mean on the wallet total (when it blinks) should have a tooltip of the description of the incoming transaction(s) ?

[SRoulette]

RE: the tooltips for incoming transactions - do you mean on the wallet total (when it blinks) should have a tooltip of the description of the incoming transaction(s) ?

Perhaps like a msn popup showing label (if defined) or recipient address that times out (hides) after a user configurable time.
It is handy when you are expecting a transfer back.

I like to place a bet then go back to web browsing while waiting for my result to come back in.

We will be donating 1.411 BTC to your donation address to aid your efforts, expect to see more from us in the future .

edit: donation txid

[Grouver (BtcBalance)]

I noticed today within my company when I wanted to show them Multibit, aspecially people within a company don't have Java installled cause of the risks of a malware infection  when they forget or don't update there Java.
Are you planning on making Multibit compatible with some other format that will run on a computer without Java?
Sounds stupid, but when Bitcoin will grow big many people will choose another client simpy cause of they don't want or are not allowed to install Java on there computer.

[jim618]

@SRoulette - thanks for your donation !

RE: desktop popup notifications. These are very useful but they do introduce more complexity because they are dependent on the operating system. Due to limited manpower I avoid anything that is different between Windows/ Mac/ Linux wherever possible. Things like the bitcoin URIs and shortcuts are quite time consuming to get working as they are all different on different OSes. They also are a test burden. There is just so much ground you can cover with a single person.

I understand that you are after better notification when the MultiBit screen is hidden/ minimised so I will have a think about that.


@Grouver
Interesting that you are demoing bitcoin software in your company ! :-)

MultiBit (and bitcoinj) is dependent on Java for pretty much everything. If a user is not allowed to run/ install Java then you are right they would have to use a different client. I do not think there is a way round this.

For a demo or any situation where you are not sure of the host machine you can prepare a USB drive with:

1) MultiBit installed
2) A Java runtime that the installed MultiBit uses to run.

This pretty much guarantees it will run (unless the host machine is really locked down).

You can install Java on a USB drive with:
http://www.dreamincode.net/forums/topic/42544-putting-java-on-your-flash-drive/

One of the items on my list of TODOs is to make a MultiBit Portable that will run off a USB drive but until then it will have to be a bit hackey to get it working. I can give you more details if you are interested.

[SRoulette]

Could you add a button to set MultiBit as the default URI handler for bitcoin ?

I discovered there is not a easy way to change it back after testing another client that also supports bitcoin URI's

[molecular]

some feedback/questions: I just checked out multibit for the first time together with my brother (recovered some coins from an old electrum wallet and we imported a private key).

• How is the change address chosen? It seems (unlike satoshi client), multibit does not generate new addresses on it's own but uses some existing address for change. Why is that? I'm assuming to solve the "wallet backup problem"?
  
  The change address used is the address of the first transaction input consumed. This is mainly for simplicity but yes it does solve the wallet backup problem (at the cost of some anonymity).
  
  
• It seems funds are unspendable until the previous tx is in a block. Why? (this could be pretty annoying, say in case I want to send money to multiple different recipients. I would have to wait for a block in between each transaction)
  
  This is in currently because MultiBit does not have all the transactions to crosscheck that the transaction inputs are actually spendable. Talking to Jan (BitcoinSpinner) at the conference he mentioned that it IS possible to spend your unconfirmed change without it causing problems to downstream transactions so I plan to look into doing this.
  The reason it is in there is that I don't want transaction inputs that are unconfirmed to "percolate" through to chained transactions. In that situation you can have a chain of unconfirmed transactions all waiting on the very first. (If the first transaction was dust you could have a whole chain waiting for a LONG time and it creates a very poor user experience). Bitcoinspinner has access to all the transactions in a db I think so the situation is not quite the same so I need to test it out thoroughly.
  
  
• A suggestion regarding key import: I expected to be able to import a private key by pasting it into some textentry field. Instead we had to generate a file (we u
  
  

sed key export to see what the format was). We didn't know what to use for the date and so we used todays date. As we later discovered this was a mistake, we should've entered the date the last tx on that address had taken place (we did a blockchain rescan afterwards to fix it). So the suggestion: in addition to being able to import keys from file, maybe a textbox to paste a private key could be offered. After that, a popup or something could ask for the rescan-timepoint and explain what it is about)

The MultiBit key export/ import is designed primarily for backing up the MultiBit wallets and giving people the actual key values. I agree it would need more work before it was a general purpose key import tool.
The main limitation is that MultiBit (currently) needs to go back and redownload and replay all the blocks from the key's "birth". It does not store all the transactions, only the ones for EXISTING wallet keys. When I do an import I need to know the age of the key. For keys coming from a MultiBit wallet I know the age of the private key and hence can write it out with the key data. (That is why it is a file and not a text box).

An example of this: Piuk (blockchain.info) wrote some import code for MultiBit for his encrypted wallet backups he mails out when you do a spend on blockchain.info. Unfortunately he does not keep the age of the key so when I import one of his wallet backups I have to go right back to the genesis block and reload all the blocks. This is incredibly slow. If it  "gets you out of an emergency" it is acceptable but for general use it is not really quick enough.


[/li][li]
A sort-of bug (likely not multibit fault, probably not even fixable from multibit source): My brother uses a window manager called "notion" (formerly "ion"). At times something gets screwed up and menus (both when selecting from main menu and also the context menu when using right-click on, for example, a transaction) appear offset to the lower right (by many pixels, somewhere completely else in the window) and menu items cannot be selected with the mouse. Once it starts occuring it keeps occuring with the same offset. A frame-resize doesn't help, but putting multibit into another frame (re-attach) does. This might not be worth investigating since it's most likely notions fault, just thought I'd let you know anyway.
I am not sure I can do much about this one.
[/li][/list]


[/list]

Other than that our experience has been satisfying. Thanks for a great open product!

Comments inline in blue.

Cheers!

Thanks, jim, four your answers. It all makes sense now.

Have you considered (for solving the "key import rescan" problem) using the help of a stratum server? I'm not sure this is a road you want to go down, but it's probably an option, right? The stratum protocol (google doc linked from stratum thread) defines a "blockchain.address.get_history" function that could maybe used to identify relevant blocks to rescan. The protocol definition isn't detailed yet, so one would have to look at server implementation to see if this function (or another one) is adequate.

I'm pondering writing a java stratum client/protocol impl for another project.

[jim618]

It seems sensible that all the bitcoin URI aware clients should work nicely together.

Which operating system are you working with and what is the other client (for testing) ?

If you have (or create) a github account you can raise it as an issue in github at:
https://github.com/jim618/multibit/issues

It is a bit easier to track bugs/ feature requests in there rather in this thread. (This thread tends to be a bit unstructured).

[jim618]

Giszmo has pledged 1 BTC for the completion of the Farsi/ Persian translation of MultiBit:

https://bitcointalk.org/index.php?topic=94805.msg1240857#msg1240857

There are about 346 terms remaining to do.

If you are a Farsi speaker (or know of one) and fancy picking up the bounty, go to:
http://translate.multibit.org

[jim618]

Thanks, jim, four your answers. It all makes sense now.

Have you considered (for solving the "key import rescan" problem) using the help of a stratum server? I'm not sure this is a road you want to go down, but it's probably an option, right? The stratum protocol (google doc linked from stratum thread) defines a "blockchain.address.get_history" function that could maybe used to identify relevant blocks to rescan. The protocol definition isn't detailed yet, so one would have to look at server implementation to see if this function (or another one) is adequate.

I'm pondering writing a java stratum client/protocol impl for another project.

Hi molecular,

Yes, technically it would be possible to have the network layer of MultiBit to talk to a stratum server but it isn't in my plans.
The current MultiBit code uses the bitcoinj network code (the Peers and PeerGroup) directly so, thankfully, I do not have to go anywhere near the actual socket management. Miron Cuperman has done a lot of work on the Peers - lots of threading work in there - and I use that directly.

I have committed to implementing the client side part of Matt Corallo's server side Bloom filter work so that will be the next network upgrade for MultiBit. The implementation is different to stratum but it's all about taming the blockchain so the end results should be similar. Syncing should be O(the number of keys in the wallet) rather than O(the size of the blockchain) which is a big improvement.

In the refactoring to add in the Bloom filters I want to separate the network layer and the UI layer a bit more. This should make it easier to add in other network connections (hopefully). I can see a connector to the OpenPay network coming up soonish and there will no doubt be other sorts of network nodes appearing in the future.

I think a java stratum client impl would be very useful - not least because you could write a very nice native Electrum Android app with it !

:-)

[molecular]

Hi molecular,

Yes, technically it would be possible to have the network layer of MultiBit to talk to a stratum server but it isn't in my plans.
The current MultiBit code uses the bitcoinj network code (the Peers and PeerGroup) directly so, thankfully, I do not have to go anywhere near the actual socket management. Miron Cuperman has done a lot of work on the Peers - lots of threading work in there - and I use that directly.

I have committed to implementing the client side part of Matt Corallo's server side Bloom filter work so that will be the next network upgrade for MultiBit. The implementation is different to stratum but it's all about taming the blockchain so the end results should be similar. Syncing should be O(the number of keys in the wallet) rather than O(the size of the blockchain) which is a big improvement.

In the refactoring to add in the Bloom filters I want to separate the network layer and the UI layer a bit more. This should make it easier to add in other network connections (hopefully). I can see a connector to the OpenPay network coming up soonish and there will no doubt be other sorts of network nodes appearing in the future.

That bloom stuff sounds interesting. Can you point me somewhere to read up on it? It's unclear to me: is this something that needs a server or is this some indexing and stuff done in the client?

I think a java stratum client impl would be very useful - not least because you could write a very nice native Electrum Android app with it !

Not to downplay electrum4android, it's fully functional and actually a good full-fledged client... unfortunately it's a bitch to install (not doable for grandma or even daddy) and the user experience is a bit uber-geeky. So I agree: the possibility of an android electrum client adds quite a bit of incentive to making that stratum client java lib. I haven't taken a look, but I guess bitcoinj has all the crypto, signing, encoding, ... functions and structures already in place... so it doesn't seem far-fetched.

[jim618]

The Bloom filter work needs changes both to the client and bitcoind - here is the little graphic I put in my London conference talk:

http://multibit.org/postImages/bloom.png

The client creates a Bloom filter for all the bitcoin addresses s/he is interested in and then gives it to bitcoind.
Bitcoind then filters all the transactions and only sends back the ones that have a Bloom filter hit.
(You get some false positives which helps on privacy).

It is a bit more work for the bitcoind but it has to send back less data so for the server it is probably a wash. The big win is for the client and the data bandwidth needed drops dramatically.

I am not sure there are any formal specs for it yet as it is still being developed.
I expect MultiBit and Andreas's wallet will be the first ones to implement it.

I am pretty sure bitcoinj has the tools to implement an Electrum client. All the signing etc would be similar. The work would probably be in the conversations with the Stratum servers for them to give you the data you want. And probably the data objects are different so there is a bit of translation there.  All doable - quite a nice project.

I know Andreas's Bitcoin Android Wallet is open source so I dare say you could fork/ reuse that to save time on UI work (obviously asking Andreas and rebranding it to avoid any confusion).

[Mike Hearn]

Actually Matt has implemented bloom filters in bitcoinj already. It's just pending merge. So you don't need to do any work Jim, just keep up with bitcoinj and at some point you will get this feature "for free".

Once bloom filters are implemented and rolled out across the network, I don't see any reason for Stratum/Electrum-style servers any more. With some more optimization you can theoretically match their efficiency but without any need for a semi-trusted server.

[jim618]

I like the sound of free !!!

:-)

[Mike Hearn]

On the Java issue -  Java as an app-specific runtime is not a security issue, the problems start when you expose it to the web and start downloading and running random untrusted code on it. Then it's an issue.

I don't see why MultiBit couldn't just bundle a JRE with itself. That's the usual way to handle lack of a JRE or lack of backwards compatibility in Java.

In the event that a native binary is absolutely required, it could be done using this:

http://www.excelsior-usa.com/jetinternals.html

It's proprietary, but free for non commercial use. It might make sense to package/ship MultiBit with that edition.

There's a free software equivalent called GCJ but it doesn't do Swing, so you'd need to either port to SWT or alternatively, the MultiBit code could be carefully factored such that native UIs for each platform can be written in native code. GCJ lets you access Java APIs and classes just like you would in regular C++, so the core logic and code can all be in Java and then Objective-C++ used on the Mac, GTK on Linux, whatever is currently in vogue on Windows. It's obviously a lot more work but the end result would be a native binary with no JVM dependency, that used the native UI toolkits.

For that to happen somebody with a passion for native UI on their platform would have to step up. I was hoping at some point to get the native version of bitcoinj up and running with nice docs, etc, but didn't have enough time to really finish the work.

[firefop]

Yes that is the plan exactly as you state.

The work I mentioned on protocol buffers (which is a data storage format that is easy for both Java and C++ to read) is a good opportunity to add that information into the wallet.

Also with bitcoinj you can have several wallets 'listening' to the transactions coming from the network simultaneously. I will be using this with the multiple wallets screen.

Note that any MultiBit wallets created in 0.1.3 will have an upgrade path for any wallet format changes so people probably won't even notice the change.

Here's a better idea - why not simply start an instance for each wallet - and have tabs to control them.

[jim618]

@firefop
I am not sure what you mean from your description.

Do you mean to have separate instances of MultiBit running, one each for each wallet?
Or something like a browser, where there is one tab for each wallet ?

In the former case, you have probably noticed that you can only run one copy of MultiBit at a time. This is because it is frequently writing out updates to the wallet files. Having multiple processes writing to the same file (e.g. two copies of MultiBit having the same wallet open) is very tricky to do 100% reliably.

In the latter case, the list of wallets in the 'Wallets' panel are functionally the same as tab headings but just arranged vertically instead of horizontally. They are styled on Microsoft Outlook. Arranging them vertically leaves the horizontal dimension (i.e. the current tab headers) to swop between functions.

[firefop]

@firefop
I am not sure what you mean from your description.

Do you mean to have separate instances of MultiBit running, one each for each wallet?
Or something like a browser, where there is one tab for each wallet ?

In the former case, you have probably noticed that you can only run one copy of MultiBit at a time. This is because it is frequently writing out updates to the wallet files. Having multiple processes writing to the same file (e.g. two copies of MultiBit having the same wallet open) is very tricky to do 100% reliably.

In the latter case, the list of wallets in the 'Wallets' panel are functionally the same as tab headings but just arranged vertically instead of horizontally. They are styled on Microsoft Outlook. Arranging them vertically leaves the horizontal dimension (i.e. the current tab headers) to swop between functions.

so why not simply open all the wallets - then you wouldn't have to worry about your zero% issue - or would that increase the footprint of the software too much?

[jim618]

All the wallets in the Wallets side panel are open, in the sense that their contents are all in memory and will receive any payments. They are all "live" and hooked up to the Bitcoin network.

You could have every wallet open in a separate window but then you have a lot of windows (and lots of window decoration).
Compare it to a browser like Safari or Firefox: you have lots of pages open in tabs but you only view one tab at a time.

There is an idea in UI design to have "global overview, detail on demand". The Wallets panel is the global overview part (together with the header region actually) and then the tabs are the "detail on demand".
There is also a level of "more detail on demand" with:
+  the transactions details popup
+  the twisties in the single wallet panels
+  the side panels in the 'Request' and 'Send' tabs.

You optionally chose to view these when you want more details.

If you open each wallet in a separate window, you lose the global overview.

Also, if you think more generally, a wallet is a thing in its own right and it is useful to have a graphical representation for it.
UI work is incredibly timeconsuming so I am not there yet. But with a graphical representation of a wallet you can do things like drag and drop to order them etc.

There are often different ways to show the same information with UI work. For my overall metaphor I have used things like Microsoft Outlook and Quicken. These work pretty well and are displaying information with roughly the same structure/ hierarchy.
 

[phelix]

Just want to shout out:

MultiBit is awesome.

Wallet management seems like a good pragmatic alternative to Coin Control / Sendfromaddress.

Looking forward to wallet encryption.