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

Yes my understanding is that the bloom filter support will go into bitcoind (I don't know when though). It will be very useful when it goes in.

RE: the old transactions - I think you would have to set the head of your local blockchain and work forward, unless there is something on the bloom filter API to cater for this (I don't know this).

The bitcoinj Wallet is an impl yes - the MultiBit Wallet is practically the same.
I would not copy what I have done in MultiBit actually but do what Andreas does which is:
1) Have a fork of the bitcoinj code and then add in support that you want
2) When bitcoinj changes then rebase and pick up the changes.

Wallet is a bit too tightly coupled to the current network/ datamodel at the moment - Mike has it on his TODO list to prise them apart a bit.   I think a Wallet abstraction would be really useful to handle heterogenous wallets (watch only, scrypt+AES encrypted private keys, HD deterministic, Electrum deterministic) but the MultiBit code is quite a long way away from that currently.

I think for writing a Java Electrum client now, the clearest way would be to use the bitcoinj datamodel as far as possible but add in the "best" structures for Electrum's wallets. That way in the future it will be easier to determine what a Wallet really is (interface wise I mean).

I have set up a bounty address for anyone who would like to contribute to the Farsi/ Persian translation of MultiBit.
This is inspired by this thread:
https://bitcointalk.org/index.php?topic=94805.0;all


The bounty address is: 1K6EJJYftWNyhre3codjT4jWyczrdRVG1n
Or, as a QR code:


The terms of the bounty I have added to: http://multibit.org/ (below the screenshots)

Jim, I think I understand how bloom filter works now and it seems it's exaclty what's needed here for multibit and light clients.

However, I'm still confused on 2 points:

• Are you saying bloom filter support will go into mainline satoshi at some point?
• "Bitcoind then filters all the transactions and only sends back the ones that have a Bloom filter hit.": What about old transactions? Afaik there's currently no index for this in bitcoind, right? So will the bloom bitcoind rescan the blockchain to send info on past events concerning the filtered addresses?

Exactly my thinking, already checked out his code last night to take a look

Offtopic sidenote and thoughts: I also took a very rough look at bitcoinj. My idea to make a "class ElectrumWallet extends Wallet" will not work cleanly (for example, Wallet.addKey(ECKey x) would have to be implemented, which wont work for electrum wallet system because keys are generated from a seed). I was kindof expecting an "interface Wallet"... Will probably take a look at multibit wallet abstraction, maybe an electrum wallet impl could be written for multibit?

Thanks !

The wallet encryption you can try out now with the beta downloads at:
https://github.com/jim618/multibit/downloads

I have been using the encrypted code for real for about a month now - they just need another round of QA and getting the code into bitcoinj. As long as you are careful to keep your wallets/ keys backed up you should be ok.

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.

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.
 

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?

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

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

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.

I like the sound of free !!!

:-)

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.

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

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?


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.

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 !

:-)

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

https://bitcointalksearch.org/topic/m.1240857

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

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

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

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