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!