Looking really good, Jonas! Love that fee calculator too, awesome idea!

Would be great if you could get this running on 10.6 or earlier; we felt so terrible leaving those systems out in the cold.

Looking good.

I love it!

Yes. I was focusing (to) much on UI. Will implement this soon.


There are some typos... and unfilled i18n fields
Thanks for that

How are you doing all this stuff? Are you hacking on a local copy of BitcoinJKit, or submitting patches to the Hive guys, or ... ? Also did you check out the cppjvm bindings or are you doing manual JNI?

OK. Good to know you found something that works for you. If you want to try switching to the cppjvm generated bindings let me know. I was able to make it spit out wrappers that looked fairly natural C++:

https://github.com/mikehearn/cppjvm/blob/master/mytest/bcj-hello-world.cpp

The size limit should be 2^32 - 1. Should be enough for giant wallets.
I also read that it should be written somehow atomically (as you do with bitcoinj wallet files) to ensure keychain integrity.

It's marked as "experimental" because of a lack of testing.
But it might be also a good idea to store just the AES encryption key. Then it's quasi a key in a keystore (osx) for a keystore (wallet file), which should be fine.
My concerns are, that the keystore is default tied to the login credentials. What if someone want's to have "another level" of security and use another password for his bitcoin wallet.

I need to rethink the whole keychain store when i have some free minutes in my mind.

Keep it open to a maximum of Bitcoin implementations is a good idea!

The problems i face with pull requests are:
- Hives BitcoinKit.Framework share the same interface for multiple Bitcoin implementations (currently bitcoind and bitcoinj). I did add some features like managing multiple addresses to the bitcoinj side. I was not able to also write the implementation for the bitcoind side. A pull request would end up in having a half/half implementation (unless somebody writes the bitcoind counterpart).
- I removed the bitcoind side and renamed the framework from BitcoinKit to BitcoinjKit. Merging Pull-Requets might give some work.

As mentioned before: as long as bitcoind seams not to be end-user capable, i would recommend to not support both implementations. In my eyes, bitcoind is something for root servers (or VPS). Running bitcoind on a normal machine will end up in having around 20%-30% of your resources consumed by bitcoind. During the catch-up even much more.

I'd like to invest (work) in a wallet that can be run all the time in background without loosing your computers resources.

What if the Hive version of the framework would also drop bitcoind support as long as it makes no sense? Drop means not deleting the implementation. I think it's more about moving it to another non-master branch and take back the work as soon as SIPA has done his thin client mode in bitcoind.

</jonas>

right!

By storing the wallet in the keychain (whole wallet file), the user could make sure, nobody can grab his harddisk and steal his bitcoins.
By adding a AES encryption to the wallet (bitcoinj layer), and than store the wallet as written above to the keychain, the user could make sure, no malware can easily access his bitcoin wallet.

I think storing the passphrase into the keychain will decrease security.
The user should pick a password and not store it in the environment where the app "lives" (should keep the pass in his mind).

Mike. What do you think about integrating tools like "Google Authenticator" to the AES leayer (instead or and a passphrase)?

</jonas>

As I type this, my login keychain is locked. I can't access stored passwords or notes without first entering my keychain password.