Design the wallet of your dreams

[Mike Hearn]

A few days I discovered that there's yet another SPV wallet app being developed on top of bitcoinj, meaning we have:

• MultiBit
• Bitcoin Wallet for Android
• Hive
• MacWallet
• Bitcoin Touch for Ubuntu

So I want to plug this fact and remind people that it's never been easier to design and build the wallet of your dreams. You can do it in any language on this list, which includes Python, Ruby and JavaScript with simple "out of the box" usage, and we're making it easier over time to use C/C++/Objective-C if those are your cup of tea too.

Let me show you how easy it is to build a simple, attractive wallet app. It has the following features:

• Runs on Windows, Linux and MacOS
• Can fully catch up with the block chain in a few seconds, even for new users.
• Has a progress bar that watches sync progress and slides off the screen when done. An address to send money to fades in when synced.
• Has a clickable Bitcoin address that will either open a different wallet app, or show a QRcode, or copy to the clipboard.
• A button that lets you empty the wallet out, when you're done with it.
• A widget (in the send coins screen) that validates the Bitcoin address has no typos in it, and highlights the edit in red if it does.
• It lets you spend unconfirmed transactions, although changing that is just one line. So money turns up immediately.

It is not meant to be a full wallet app and does not have a list of transactions, exchange rates or other such things, although those would not be hard to add.

Open the wallet-template code in a new tab.

It's written in Java 8, which is more or less like your fathers Java except with easy lambda functions, support for some functional programming stuff and a nice UI toolkit. You could write such an app in lots of other languages though, and the code would probably be shorter.

Take a look at Main.java and see the code that creates the WalletAppKit object. That's all you need to bring up a connection to the P2P network and synchronize a wallet with it. Easy.

Go look at the Controller class. It handles the UI logic for the main screen. It's simple - the largest method in this class simply sets up the animation that runs when the blockchain sync is finished. It also wires up the wallet balance to the UI.

Open SendMoneyController. It handles the UI logic for the send coins screen. After the user enters a valid Bitcoin address, it creates a transaction that sends all the money in the wallet to that address (you could ask the user to enter an amount of course). Then there's some code to handle popping up a crash window if something goes wrong, and updating the UI to reflect the transaction as it propagates across the network. Actual logic here is about 50 lines of code, max.

In the controls directory, you can see two classes that manage working with Bitcoin addresses. One of them can be used to make an edit box validate an address and enable/disable buttons depending on if it's valid. The other creates a clickable address widget that can also display a QRcode.

The utils directory contains a variety of misc utilities that aren't Bitcoin specific, like for popping up themed alert windows and so on. It's not relevant here.

I hope you will agree that this isn't much code. The UI layouts are all edited with the free Scene Builder app.

Put simply, if you have even basic programming experience and you aren't happy with existing wallet apps, now is the time to design the UI of your dreams. All the heavy lifting is handled for you by the frameworks and you're left to just draw on the canvas and make the app work how you want.

[jim618]

Great work Mike.

Let a thousand wallets bloom !

:-)

[mikegogulski]

Hm. I've been using MultiBit for a few months (not always happily: strange GUI wonkiness in xubuntu, sometimes ranging to extreme wonkiness. No sign those are bitcoinj issues, though.)

What's the ++ for this over MultiBit?

[Mike Hearn]

This isn't about a new wallet app but rather just encouraging people who might have previously been put off by the complexity to think about maybe making a new one.

[jim618]

Hm. I've been using MultiBit for a few months (not always happily: strange GUI wonkiness in xubuntu, sometimes ranging to extreme wonkiness. No sign those are bitcoinj issues, though.)

What's the ++ for this over MultiBit?

Hi mikegogulski,

If there are specific things it would be good to raise them as issues in the github issues db, which is here:
https://github.com/jim618/multibit/issues

Due to the number of users of MB now it is getting a little difficult to change it radically - I am mainly doing bug fixes etc. This is one of the reasons we are going to basically fork things when we do the HD wallets as we can refactor things a bit.


Anyhow, getting back on topic : for devs who have their dream wallet in mind IMO bitcoinj is the best library to use to implement their Bitcoin network code.

[hivewallet]

It is indeed great to see so much happening here!

One point though, Mike: To make this truly easy and for the options to really grow and flourish, we need more easily bundled VMs. Unfortunately we had no luck getting any of your instructions to work in that regard; we are not Java folk, and there were many quirks with the OS X stuff in particular. Would you be able to put some time into helping us with this (by which we mean, just doing it)? Obviously all of the work goes back out to the community and we can at least be sure that the work will also directly benefit MacWallet, if not many more to come...

[jim618]

Hi Wendell,

I've got the javafxpackager working for MacOS and Windows with it bundling the Java 7.0_25 JRE ok.

Currently this is in the branch issue-207 in the MultiBit code. It won't get merged into the MultiBit Classic code but will go straight into MBHD. (it's a completely different build really).

We weren't planning to bundle a JVM for Linux as a user can easily use yum or whatever.


There is a gotcha however. To build and sign a Mac DMG you need a Mac, and to build and sign the Window installer you need a PC. Thus in the issue-207 build (which is run on a Mac) I prep a directory with all the Windows build artifacts, manually copy it over to a netbook, build and sign them there and bring them back.  A bit of a PITA but the result is a nice installer, all authenticode signed and everything so it is worth it.

Gary and I will be working on MBHD in earnest in a couple of weeks so you could wait until then or reverse engineer the issue-207 branch if you cannot wait.

[hivewallet]

Hi Wendell,

I've got the javafxpackager working for MacOS and Windows with it bundling the Java 7.0_25 JRE ok.

Currently this is in the branch issue-207 in the MultiBit code. It won't get merged into the MultiBit Classic code but will go straight into MBHD. (it's a completely different build really).

We weren't planning to bundle a JVM for Linux as a user can easily use yum or whatever.

There is a gotcha however. To build and sign a Mac DMG you need a Mac, and to build and sign the Window installer you need a PC. Thus in the issue-207 build (which is run on a Mac) I prep a directory with all the Windows build artifacts, manually copy it over to a netbook, build and sign them there and bring them back.  A bit of a PITA but the result is a nice installer, all authenticode signed and everything so it is worth it.

Gary and I will be working on MBHD in earnest in a couple of weeks so you could wait until then or reverse engineer the issue-207 branch if you cannot wait.

Right! We'll check out the branch and speak tomorrow internally to see what the best approach is. My gut feeling though is that we're probably going to reverse engineer what you have. This is the one point that has been absolutely depressing for the last few months, and if you have solved it, then OMGWTFLOL, you wonderful, beautiful people!

[mikegogulski]

This isn't about a new wallet app but rather just encouraging people who might have previously been put off by the complexity to think about maybe making a new one.

Ah, I grok. Good stuff.

[jonas.schnelli]

Hi Wendell,

I've got the javafxpackager working for MacOS and Windows with it bundling the Java 7.0_25 JRE ok.

Currently this is in the branch issue-207 in the MultiBit code. It won't get merged into the MultiBit Classic code but will go straight into MBHD. (it's a completely different build really).

We weren't planning to bundle a JVM for Linux as a user can easily use yum or whatever.

There is a gotcha however. To build and sign a Mac DMG you need a Mac, and to build and sign the Window installer you need a PC. Thus in the issue-207 build (which is run on a Mac) I prep a directory with all the Windows build artifacts, manually copy it over to a netbook, build and sign them there and bring them back.  A bit of a PITA but the result is a nice installer, all authenticode signed and everything so it is worth it.

Gary and I will be working on MBHD in earnest in a couple of weeks so you could wait until then or reverse engineer the issue-207 branch if you cannot wait.

Right! We'll check out the branch and speak tomorrow internally to see what the best approach is. My gut feeling though is that we're probably going to reverse engineer what you have. This is the one point that has been absolutely depressing for the last few months, and if you have solved it, then OMGWTFLOL, you wonderful, beautiful people!

I also made some thoughts about that (bundle MacWallet with JVM).
But on the other hand, on Mac OSX, what's the drawback when the user needs to download the "official" JVM? He can reuse the JVM for other apps.
System-wide-speaken it would make no sense to have multiple app where all of theses have their own JVM.
Isn't that also the nature of Java to have one JVM on the system?

What i really would love would be a C++ version of bitcoinj (or some cross compiling). Mike also has a branch on that. But it's also a nightmare to dig into this (because of the nature or GCJ).

A C++ version would give more flexibility in my eyes. C++ runs on probably all OSs (including Android throughout NDK).
If bitcoinj would exists as C++ library, it would be even more easy to write wallet apps. It would also help to make partial use of bitcoinj features for embedded systems (signing transactions, etc.).

[Mike Hearn]

Yes, working across languages that can't operate on the JVM is the most painful part. Fortunately most modern languages can (except Haskell). Objective/C++ are the main exception, because they're so old. But it'd be the same in reverse if the library was written in C++, as then we'd need complicated bindings to operate in any modern language.

I wrote my post on the assumption that it's a good idea to build a wallet app using some JVM-supported language, because that way you get to release on all 3 major platforms simultaneously. Our userbase is spread across Windows, MacOS and Linux so platform specific wallets will always have less impact than cross platform wallets. The GUI issues that used to plague such apps aren't such a big deal anymore.

Shipping a bundled JVM as a library on MacOS is harder than it should be, although I think a part of the difficulty was the desire to "go for gold" right at the start with lightweight JVM-reimplementations and such. At the conference I showed Bayzli about the rpath/install_path tools from Apple which you need to master to make bundling of any kind of library work. Sounds like there wasn't any progress since then.

I haven't had much time for hobby bitcoinj development in recent times which is why I haven't made any progress on this. My time has been sucked up with other things. Jim used the JDK tools to do it, which simplifies things. But as Jonas points out, on MacOS the JVM installer is much better than on Windows (no bundled crapware, etc) so just asking the user to install a system JVM is a lot more feasible (or doing it for them).

I don't think C++ is more portable than Java, but even if it was, we're talking about a codebase that parses extremely complicated data structures off the wire that come from randomly selected servers which may be malicious. Doing that kind of thing in C++ (or even worse, Objective-C) is a recipe for people losing lots of money. Satoshi's code has so far avoided security problems by being very careful, mostly being single threaded and by aggressively using C++ features to avoid explicit memory and buffer management. But the result is that lots of people can't easily work with his code.

One approach I've been playing with is J2C, which transpiles Java into C++11. It isn't a working solution by itself because a bunch of stubs need to be filled out for things like atomics and creating threads/doing file+network IO (i.e. services that would be provided by the JVM), but it's a very promising approach. The generated C++ is very clean, the biggest issue with it is missing array bounds checks (the generated code doesn't give the same security properties as the Java does).

Anyway, basically I want bitcoinj to be easy to use in every language and on every platform. Most libraries don't manage that, and it will require some creative hacks to get there. But I'm sure we'll eventually succeed.

[jsuder]

I've got the javafxpackager working for MacOS and Windows with it bundling the Java 7.0_25 JRE ok.

Currently this is in the branch issue-207 in the MultiBit code. It won't get merged into the MultiBit Classic code but will go straight into MBHD. (it's a completely different build really).

Gary and I will be working on MBHD in earnest in a couple of weeks so you could wait until then or reverse engineer the issue-207 branch if you cannot wait.

Sounds great, hopefully that will finally work... To be honest we probably won't get there before you, because there's so many things to work on and only so much you can do in a week.

But on the other hand, on Mac OSX, what's the drawback when the user needs to download the "official" JVM? He can reuse the JVM for other apps.
System-wide-speaken it would make no sense to have multiple app where all of theses have their own JVM.
Isn't that also the nature of Java to have one JVM on the system?

There are good and bad sides of this. The advantage is that the JVM is shared between apps as you say, and there's less to download if the user already has one. The disadvantage is that it makes it more explicit that we're using JVM (some users might refuse to install it and just delete the app when they see it requires Java), and we're not sure for how long Apple will support such on-demand installation of JVM, as it's already considered deprecated...

I don't think C++ is more portable than Java, but even if it was, we're talking about a codebase that parses extremely complicated data structures off the wire that come from randomly selected servers which may be malicious. Doing that kind of thing in C++ (or even worse, Objective-C) is a recipe for people losing lots of money. Satoshi's code has so far avoided security problems by being very careful, mostly being single threaded and by aggressively using C++ features to avoid explicit memory and buffer management. But the result is that lots of people can't easily work with his code.

I would say ObjC itself isn't any less secure than Java in this regard, because everything is object-oriented and you don't normally do any C-style memory management yourself; that is, unless you get down to the C level, because ObjC is technically a superset of C (or almost a superset), and if someone were to write such code in ObjC then they probably would be tempted to use plain C structures a lot for optimization reasons...

[ManaUser]

First and foremost, the wallet of my dreams must never impose ANY restrictions on the user. It can warn that what I'm going might be rejected by the network, but it should always always let me do it, no matter how stupid it thinks my request is.

Second, the wallet of my dreams would definitely not depend on Java.

[Mike Hearn]

You can certainly build a wallet that meets the first criteria, if you want. bitcoinj will let you build any kind of transaction, including ones that won't confirm or would be rejected by the network.

For the second criteria, why? You think it's insecure?

[jonas.schnelli]

Second, the wallet of my dreams would definitely not depend on Java.

You probably mean, that the UI should not look like a typical Java application.
Or where do you see problems with java when it's been used as for the bitcoin sublayer/library?

[ManaUser]

For the second criteria, why? You think it's insecure?

Well it's certainly had it's share of problems recently on that front, hasn't it? I realize that mostly related to using it in the web browser, rather than with local programs, but security is definitely a concern. I also dislike how aggressively Oracle pushes their propriety version and how even open source projects seemingly go along with this (i.e. "For best results, use with Oracle" etc.). And finally, it's a trivial gripe, but I do prefer native applications just for the sake of not having to install yet another support package.

You probably mean, that the UI should not look like a typical Java application.
Or where do you see problems with java when it's been used as for the bitcoin sublayer/library?

So no, surprisingly I meant what I actually said. But now that you mention it, Java programs do tend to have crap UIs. I can't comment on whether this applies to the bitcoinj based clients mentioned above as I have not tried them. I may yet do so considering the dearth of appealing clients in general.

[Mike Hearn]

Yeah, the security issues are to do with downloading and running random programs without any trust decisions being involved. Although I understand it, this argument doesn't really work - I could argue that native apps are insecure because of ActiveX, and it'd make as much sense.

The other issues are I think better. But, bitcoinj runs on Dalvik and OpenJDK just fine. These days it's easier to bundle the JRE up with an app as well (I mean, if you use the standard tools, which aren't meant for native apps using the JVM as a library).

You can make crap UI's with any platform. Making a wallet app with a UI you love is exactly what I'd like to see happen.

[pjv]

For me, as a developer, embedding a comparatively giant, general purpose VM inside my relatively simple, purpose-built (one thing well) application feels pretty wasteful and inefficient. It's an aesthetic thing, I guess.

As far as the UI's of the mac bitcoinj clients are concerned, MacWallet and Hive are native and have nothing to do with clunky java UI's. Multibit... kinda java ugly, but I trust it and use it.

[Mike Hearn]

MultiBit is using Swing which is pretty old. You can make UI's that are virtually identical to native on MacOS these days, if you use the more modern toolkits:

  http://aquafx-project.com/project.html#examples

Here's an old video of a wallet app I knocked up: http://www.youtube.com/watch?v=0h_1pM_phuc&hd=1  - I think it looks OK.

With respect to disk space usage and such, that used to bother me too, but I've got old. Doing it another way means rewriting code over and over for all 3 major platforms (or 4 if you include Android). Things like Qt help, but then you're back to not having a native UI anymore and you may as well just go all the way.

Hive is a good example of this problem. They want to support other operating systems, but their app is a Cocoa app. So to support another platform really means rewriting the app from scratch. I'd rather have a bigger download, ship a portable runtime and save the time spent fiddling with platform specific stuff. The time saved can be spent on features instead. These days the problems with ugly UIs and startup times are much less severe than they once were.

[creepywheepy]

That's cool! I haven't even supposed to think that I am able to make my own design of wallet without. I was thinking you'd be a proffi in programming to create it