[VanillaWallet v0.5] The friendly Bitcoin wallet.

[Nyhm]

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



Built with bitcoinj. Community feedback is most welcome.

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

[finkleshnorts]

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

[scintill]

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.

[nimda]

I don't know if this is possible but if I could point to a bitcoin folder and it could just piggy back off the blockchain there that would be cool but i guess that would have to be a BitcoinJ feature really.

Have you heard of NTFS hardlinks?

[John (John K.)]

A spelling mistake in your FAQ :

When VanillaWallet runs, it will look for these files in tehcurrent working directory and create them if needed.

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

[nimda]

Is the vanilla.wallet file encoded?

No

[finkleshnorts]

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

[nimda]

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.

[finkleshnorts]

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

[jim618]

Hi Nyhm,

I have been playing around with VanillaWallet this afternoon.

Have a look at the screen shot below:



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

[Nyhm]

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

[nimda]

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.

[John (John K.)]

Hi Nyhm,

I have been playing around with VanillaWallet this afternoon.

Have a look at the screen shot below:



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

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.

[Nyhm]

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.

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.

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

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.

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.

[molecular]

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.

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.

[Nyhm]

Regarding open source, I just re-discovered my own comment regarding the fact that my vanity address generator applet is also not yet open source:

Closed Source: The applet code I've written is not (yet) open source. You really shouldn't trust any security-sensitive software that is not open source.

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

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.

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.

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

[molecular]

Regarding open source, I just re-discovered my own comment regarding the fact that my vanity address generator applet is also not yet open source:

Closed Source: The applet code I've written is not (yet) open source. You really shouldn't trust any security-sensitive software that is not open source.

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

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.

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.

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.

[apetersson]

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

[Andreas Schildbach]

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.

[Nyhm]

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

Then your security isn't that high, if you can't open source it, your not doing something right on the security end, because you can decompile jars. Also closed source and not having time to give is bad, cause if you opened source I think people would jump on and help write the code, and fix little bugs, making your job easier.

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.

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 .

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.

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

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.

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.

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!