Topic: [VanillaWallet v0.5] The friendly Bitcoin wallet. (Read 5371 times)

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.

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

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

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.

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.

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

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':



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

VanillaWallet v0.3 (Alpha) Released! 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.

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

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! The Kickstarter project is for Island Forge (not VanillaWallet or Bitcoin, but I am accepting bitcoin at islandforge.com). Here's the bitcointalk.org topic: https://bitcointalksearch.org/topic/island-forge-single-dev-mmorpg-accepting-bitcoin-kickstarter-91399

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

Inspired by your comments, I've released VanillaWallet v0.2 (Alpha)! See the (new) changelog at 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.

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!

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.

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

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.

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:


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

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.

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.

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.

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.