Bitcoin Forum

VanillaWallet: The friendly Bitcoin wallet.

• Non-intimidating for New Users
• Refreshing for Experienced Users
• VanillaWallet aims to provide just what you need, and not much more

vanillawallet.com (http://vanillawallet.com)

http://vanillawallet.com/vanillawallet.png

Built with bitcoinj (http://code.google.com/p/bitcoinj/). Community feedback is most welcome.

UPDATE: VanillaWallet v0.5 (Beta) released Dec 4, 2012

Very cool! The world needs more bitcoin clients, especially simple ones like this.

Looks nice!  One complaint: it's not open-source, so I would be afraid to use it.  May be acceptable to beginner target audience, though.

Have you heard of NTFS hardlinks?

A spelling mistake in your FAQ :


Other than that, great work!  ;D
Is the vanilla.wallet file encoded?

No

I'm never downloading any bitcoin-related program that isn't open source.

+1. Given that it has the blockchain, bitcoinj etc, it's trivial to implement code which empties all users' wallets at once to your own.

I'm also never going to download a bitcoin-related blockchain :)

Hi Nyhm,

I have been playing around with VanillaWallet this afternoon.

Have a look at the screen shot below:

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

As the VanillaWallet file is in the bitcoinj protobuf format it can also be read by MultiBit.
Whether this is to be recommended is a different matter though !

I made some notes and first impressions and thought I would list them:

+ I like the help text - good introduction for the target you are going for.
+ You should mention that the blockchain download is only 20 MB (as blockchain equates to "gigs" in a lot of people's minds). (TBH I just copied in a multibit.blockchain and renamed it as they are compatible).
+ You don't create a log file which will make it harder for you to track down users' problems. Just use logback to put a log file in your working directory with your debug etc.
+ In your dialogs you can get the system default font and font metrics so that you can tweak the dialog size to be wide enough/ tall enough.
+ I notice that you do not give any personal identification on your website and the whois maps to dreamhost.com. As you are asking people to trust you/ your software with their bitcoin you might want to make yourself a bit more visible.

On a similar vein, you will probably get a lot more downloads if you open source your code so that people can have a look through it. It depends on if you are trying to monetise it of course but it is something to think about.

Regards,

Jim

Thank you for your initial comments, everyone!

Regarding open-source, I understand your concerns. This may be open source some day, but at least not during this initial early development. I promise there is no intentional malicious code, but I _do not_ promise that there aren't any bugs that could lose your bitcoins at this point!

As a counterpoint, how many of us download, review, then compile the open source software we run, or do we just assume there's nothing slipped into the binary or any of its dependencies? Just making a point here - I agree that security-sensitive software (or all software for that matter) should be open source, but even so, it would be trivial for any wallet author to swipe your coins.

I appreciate Jim's argument for more accountability, which I will address later in development. For now, just consider this a preview for experienced users (not quite ready for the end-user market).

Regarding the file locations, my initial design was to create a $HOME/.vanillawallet/ directory to store the chain and wallets. The reason I changed my mind was that I considered it to be simpler for users to see the files alongside VanillaWallet.jar. However, the whole notion of the current working directory is fraught with pitfalls. I'm considering file placement for the future (and even a command-line switch for the path, for better script support). I could also check both a default HOME path plus the current path to look for the files. I'm considering some other ideas, as well, so thanks for your input.

Regarding the block chain, I'm not piggybacking the Satoshi blockchain file, because (a) I want VanillaWallet to be independent of any other client, (b) VanillaWallet is based on BitCoinJ, which uses its own format (and only stores the headers it needs for the local wallet, making the chain file somewhat bound to the wallet). I'm considering including a blockchain checkpoint in the software (but the software does _not_ include any blocks at this time). At this point, functionality wins out over optimization.

Ultimately, if you're the type of Bitcoin user who will not download a client that you cannot compile yourself, or includes a blockchain snapshot, then VanillaWallet probably isn't for you! I'm _not_ (by design) attempting to make a wallet that caters to everyone. There are plenty general-purpose clients for that. I want to focus on very tight design constraints, centered on simplicity.

Thanks for catching my typographical error, John! I'm glad you like my text, Jim (and a big thank you to those who actually read the instructions).

Regarding the user interface, making it physically bigger is counter to my intended design. I want it to be small and compact. That said, I could allow you to resize the window, but that just leads to a bunch of dead space in the UI.

Regarding Jim's suggestion to use the Font Metrics... I simply hate how Java handles fonts. In all my years developing Java applications, I've never ever had a good experience dealing with fonts. Here's what I do for VanillaWallet: Create main frame with the wallet GUI elements and pack(). Then, I set the (single and only) pop-up info dialog to the width of that frame, and make the initial position look pretty. Notice that the Transactions are actually in the same dialog, which I do not resize. I'm probably trying to be too compact. I should probably separate the Transactions into their own independent dialog. Thanks for your input.

For simplicity, I turned off logging in this release build. If it encounters an uncaught exception, it should cleanly save/close (with a friendly but useless error message in the GUI), and dump the exception to standard err. This doesn't help end-users much, but then again, neither do stack traces. For these initial releases, I should definitely improve logging so the experts here can report if anything goes wrong. (BTW, I once had a NullPointerException after initial block chain download, but it was fine after restarting. Not sure what actually caused it... due to lack of logging!)

I'm pleased to have so many comments already. Here are some potential future features/enhancements:

• Encrypted wallet file (see Encrypted Wallet caveat in Instructions)
• Better command-line options (and document them)
• Blockchain snapshot (to speed up first init)
• Better logging
• Various UI visual and behavioral improvements
• Task tray integration

On a final note (for today), Jim mentioned monetization. I'm not looking to get rich, but I'm currently not in the position to spend much (any) time on this unless I can earn some coin. Suggestions? Sell copies? Require payment to unlock features? Stick with donations? Your support is greatly appreciated. (For that matter, is anyone looking to hire a Bitcoin-savvy Java developer??)

You're taking open-source entirely wrong. The idea isn't that everybody needs to audit the code, just that *someone* can. Someone can be paid to, or someone can do it out of curiosity. Basically, given the large userbase of Bitcoin, I think *someone* would have spoken up by now if it was malware.

This is the only factor that's stopping me from using this client as a pendrive based light client. I like every part of this client, but security comes before everything, especially in this Bitcoin ecosystem.

I do understand, and agree with your statement, nimda. My point was just that open source doesn't stop the Average Joe from using it. If you knew me, you'd know that I'd never advocate against open source for any security-sensitive software. At this point, the primary reason it's not yet open source is that it's just the first alpha release, I'm not prepared to release the source yet, and my initial goal was to get some feedback from the community here.


Thanks for your feedback on this, John. I'm glad you like the direction I'm taking. You're right that VanillaWallet could make for a good pendrive wallet (if you take the JRE along with you as well - you could even take multiple JREs suitable for various platforms). Also, I entirely understand why you wouldn't want to trust it at this stage.

I'm glad to hear your input, and I will work on transparency (of the code and myself), as soon as I can put some more time into it. This was just the first step (to get it out there). Further input from the Bitcoin community is most welcome.

lol. on first read I thought by "monetise" you meant "put in a wallet stealer" and you were in fact suggesting to not opensource it if he put in a wallet stealer.

Regarding open source, I just re-discovered my own comment regarding the fact that my vanity address generator applet (http://nyhm.net/bitcoin/vanityaddr/) is also not yet open source:


I wish I could justify more time toward these Bitcoin endeavors.


Ha! That's one way to monetize it. Any other suggestions?

May I suggest a "donate" feature? Maybe even a checkbox when making a transaction: [ ] donate 0.05 BTC to software author. Maybe make the suggestion a percentage of the transfer at hand ;).

You'd probably be surprised how often people are in the mood for this kind of thing.

is there any particular reason why you are obfuscating the compiled version? (renaming classes)

It's great to see a new Bitcoin client, especially one that uses BitCoinJ.

Nyhm, you said you're using BitCoinJ 0.5.2 - do you add any patches on top of that? I'm asking because plain BitCoinJ cannot do fees yet. Without fees, lots of users will see outgoing transactions not confirming.

These comments are piling up faster than I can respond! Thanks for all the feedback, folks.


Hi gweedo, I'm making no claim of this being secure at this stage in development (initial alpha). I totally agree that open source is much more secure than closed. Close source does not increase security - quite the opposite.

Open source (adding more developers to the mix) adds a lot of overhead, which is not in the cards right now. Remember, this is only the initial alpha release, which I put out there for comments. So, thanks for your input. I'm glad to have folks taking a look, and I'm looking forward to following up with improvements in the future.


There is, in fact, a donate button in the client! I didn't want to clutter the main UI, so it's on the "confirmed vs. pending" balance screen (find the Star button). It just fills in the Send screen with the donation address (and suggested donation, which can be easily changed/canceled). I don't want to add any features that get in the way or trick users into sending unintended bitcoins.

Adding a "donate on send" checkbox is an interesting idea. How do others feel about that? I'd turn it off by default. My biggest concern is cluttering the minimalistic UI, but I can probably work it in somewhere. Thanks for the suggestion.


Mainly because I use proguard as part of my standard development environment. I would have used it on the entire jar, to weed out unused classes, but it was unable to deal with all the dependencies (without further tweaking). The only value in releasing a jar with the class names is (a) debugging and (b) decompiling. I should have enabled better debugging; I'll address this in the next release. I could configure proguard to keep the class names (or just remove proguard from this project). Thanks for pointing it out and having a look around.


That's quite right, Goonie (great name, by the way). I augmented Wallet with a flat-fee of 0.0005 btc to each send (documented in the instructions).

[rant] In testing, I actually had a much worse experience. Transactions would be dropped by the Satoshi client because they didn't meet its expectation of fees. BitCoinJ never realized that the transaction was dead-in-the-water, so you'd never get access to those coins again (without dropping all transactions and rescanning the block chain, or pulling private key into another client). Basically, the Satoshi client is strong-arming others to conform to its ideals, even though it's not a requirement of the protocol. This would happen when sending any no-fee transaction with a value less than 0.001 ... which can even happen if there is change less than 0.001, which the user cannot control.[/rant] Long story short, I had to hard-wire the fee into the client.

Any tinkering I'm doing to BitCoinJ itself I'm pushing back to the project. See my nebaughman-feeschedule clone in their git repo.

Thanks everyone. Looking forward to some folks pressing that Star button!

Inspired by your comments, I've released VanillaWallet v0.2 (Alpha)! See the (new) changelog at vanillawallet.com (http://vanillawallet.com).

The code is no longer obfuscated. I took proguard out of my build process entirely. It was my mistake to include it in the first place, since it made the binary seem shady. That was not my intent.

This is not yet open source, but I recognize that this is an important aspect for the future.

Thanks to those who have tried it out and provided feedback.

You asked for more visibility to build trust, which I entirely understand. I've included a bit about myself in the instructions, including links to find me online. I've added a contact form to the site.

How's this for visibility: Who is Nyhm? See me at Kickstarter! (http://www.kickstarter.com/projects/1391235405/island-forge-establishing-a-creative-player-commun) The Kickstarter project is for Island Forge (not VanillaWallet or Bitcoin, but I am accepting bitcoin at islandforge.com (http://islandforge.com)). Here's the bitcointalk.org topic: https://bitcointalk.org/index.php?topic=91399.0

(This is also why I don't have a lot of time right now, as much as I love Bitcoin.)

AKA "Symlinks on Windows" for those who are unfamiliar with the term. What's the difference between a symlink and a shortcut? This has been asked/answered on SuperUser: http://superuser.com/questions/253935/what-is-the-difference-between-symbolic-link-and-shortcut

VanillaWallet v0.3 (Alpha) Released! vanillawallet.com (http://vanillawallet.com)

Includes platform builds (Win .exe, Mac .dmg). Can folks confirm these work on various versions of Win/Mac? I have limited resources/time to test on multiple platforms. My thanks!

Also includes some (experimental) command-line options. Run with --help for a list (I'm interested what you think of --sweep).

Other miscellaneous internal cleanup/improvements. I still consider this alpha, and would like more feedback from the Bitcoin-savvy community before widening the audience. No, not (yet) open source. Please bear with me. Your input is greatly appreciated.

Hi Nyhm,

I just tried out v0.3 on my Macbook (running OSX 10.6.8 )
It worked fine.

A few things I noticed:

In the dock the icon gets 'expanded':

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

In your icon set file you just have a single icon but if you pop in some higher resolution ones Macs will use those where they can.


Also, it would be slightly easily to copy the VanillaWallet.app onto the user's harddisk if you put a shortcut to the Applications directory in the DMG. The user can then just drag it over to the Applications shortcut. (If you are using Maven to build VanillaWallet you can copy the code to do this straight out of the MultiBit pom.xml).


It is probably on your TODO list but for Mac apps it is really easy to register your app to respond to bitcoin URIs.  It is an entry in your Info.plist. If you have a look in the MultiBit APP Info.plist you will see the entries to add. That would make VanillaWallet respond to browser bitcoin URI clicks which would be pretty neat for the user.  (You will also need something to deal with the case of a VanillaWallet already being open and handing over the bitcoinURI when the OS creates another instance - have a look at the org.multibit.ApplicationManager class for how I did it. Using a socket for both identifying if there is another instance running and passing over the data if there is works pretty well).

Thanks so much for your input, Jim. I figured the single icon in the .icns wouldn't be sufficient (will fix). Regarding your other Mac integration suggestions, I'll have to do some research later, because I'm very Mac-un-savvy (the last Apple computer I used was an Apple ][ C+). I'm using JarBundler (http://informagen.com/JarBundler/) to build the Mac bundle (and some other command-line tools to build the disk image).

I'm a bit frustrated by the UI differences I see in your screenshot. It's rather minor (button dimensions), but I've specified Metal L&F to avoid platform differences. Still, I've seen much worse when running without Metal L&F on the Mac JVM. I don't have a Mac on hand to test against, so thanks for taking the time to provide your input and screenshot.

Thanks for everyone's prior comments. I've just update VanillaWallet to v0.4. Mostly to use BitcoinJ v0.6 (with a few other technical and cosmetic improvements).

I'm calling this Beta, because there are no major outstanding public-facing features planned (except maybe wallet encryption, which I plan to implement myself).

Thank you for your interest and input.

VanillaWallet v0.5 (Beta) released with many improvements (still needs some work before v1.0).

• The user interface is streamlined and improved
• Overall friendlier for new users
• Transaction history needs improvement
• Win (exe) and Mac (dmg) may return (just jar for now)

Thanks for any feedback.

It would be nice if it had the ability to export its privkey and import a new privkey (overlaying the existing one). This is because I would like to run this client from a thumb-drive for one-time-only transactions. (Such as sweeping an existing privkey/address full of many tiny inputs into a new address.)

There are some command-line options:

java -jar VanillaWallet.jar --help
  [--help] Show this help
  [--version] Show version info
  [--log] Turn on logging (into vanilla.log file)
  [--which_wallet] Find wallet and show path
  [--export_address] Load wallet and show address
  [--export_privatekey] Show the private key
  [--import_privatekey <privkeystring>] Create new wallet with key
  [--export_transactions] Show all tx currently in the wallet
  [--resync] Resync the block chain with the wallet (runs gui)
  [--fee] Set tx fee for session (runs gui)

Some of these are mostly for debugging, and aren't well documented (or tested) yet, but the private key options may be what you're looking for.

Also have a look at BitcoinSweep (http://silverthreadsoftware.com/bitcoin/sweep/) to sweep values from private keys to a deposit address. This also needs more testing, so please report back if you decide to try it.

In either of these cases, when consolidating lots of tiny transactions, you should manually set a high enough tx fee for nodes/miners to accept your transaction. Neither VanillaWallet or BitcoinSweep are yet very smart about applying larger-than-standard tx fees. I've found this out myself - the tx will get to the point of sending, but nothing will happen (or it will get sent and show up on blockchain.info, but no miner will include it for a long time).

Great!
Thank you very much.

One more thing, since you have been so responsive. Any chance that you might someday compile apk versions of vanilla and sweep for android?

[added later] When I import a privkey, VanillaWallet says that it imported the privkey, displays the privkey's address, and tells me to launch the GUI in order to use the new wallet. But it never actually writes the new wallet to disc. So when I launch the GUI, the button "Create Wallet" is displayed. Then, of course, if I press "Create Wallet" it creates a brand new wallet with a newly generated key-pair.