MacWallet - another bitcoin wallet app

[jonas.schnelli]

I'd like to introduce another bitcoin wallet app.
MacWallet is a easy-to-use mac bitcoin wallet based on bitcoinj.
It's a thin client (SPV). It's in early development stage. Use it whise and at your own risk.



Thanks to the Hive developers (and bitcoinj!), i was able to write the wallet i always dreamed of:
- Mac global menu app
- Can easy run in background (low memory and cpu footprint)
- Always show my balance and/or a fiat/btc-ticker
- Nativ interface

It's under MIT license and the source code is available at www.github.com/MacWallet/MacWallet.

Download and Requirements
- MacWallet needs OSX 10.7 or higher as well as a 64bit CPU.
- Java Runtime Enviroment is also required and will be installed automaticly by your mac during the first start of MacWallet.
You can download a signed binary from http://macwallet.github.io.

Every feedback and every testing effort will help MacWallet to get more stable.
Report issues here: https://github.com/MacWallet/MacWallet/issues

Some screenhots:

[1714803866]

1714803866

[1714803866]

1714803866

[1714803866]

1714803866

[1714803866]

1714803866

[hivewallet]

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.

[maxmint]

Wow, very nice little app!
Small feature request: would it be possible to get a sound signal when receiving coins?

[Moebius327]

Looking good.

[Mike Hearn]

Very cool! I'm so happy to see this abundance of wallets. It's what I always hoped for.

You should check out this article:

  https://code.google.com/p/bitcoinj/wiki/SpeedingUpChainSync

That way you can make it sync more or less immediately for new users. If that's hard for some reason, let me know.

Maybe "addAddress" should be "Add Address"?

I guess you should make checking for updates on by default as well.

[kangasbros]

I love it!

[pa]

Is the wallet encrypted? Where in the filesystem is it stored?

[jonas.schnelli]

You should check out this article:

  https://code.google.com/p/bitcoinj/wiki/SpeedingUpChainSync

That way you can make it sync more or less immediately for new users. If that's hard for some reason, let me know.

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

Maybe "addAddress" should be "Add Address"?

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

[jonas.schnelli]

Is the wallet encrypted? Where in the filesystem is it stored?

Currently the wallet-file is not encrypted.
It's stored in your ~/Library/Application Support/MacWallet

Theres a cool option which get extended soon:
You can store your wallet in the mac osx keychain.
So it's by default encrypted and protected with your login credentials.


AES encryption will be added soon.

[Mike Hearn]

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?

[jonas.schnelli]

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?

I did fork the BitcoinKit.Framework (https://github.com/jonasschnelli/BitcoinJKit). There are some improvements over the Hive version. Because i dropped the bitcoind support (only bitcoinj support) i decided not to create Pull-Requests. In my eyes, bitcoind is currently not end-user ready ("normal" end users).
I would recommend the hive guys to partial migrate some of my BitcoinJKit commits. If they also drop bitcoind support, they might pull all my commits.

For storing it into the Keychain, i use bitcoinj wallet-save-to-steam functions. The wallet will never be written to a file (when activating the keychain-wallet flag).

BitcoinJKit currently uses JNI (JNI_CreateJavaVM). Complex objects are transferred between Java/Obj-C as a JSON representation. Easy and simple.

[Mike Hearn]

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

[Mike Hearn]

BTW for the keychain - are you sure there are no size limits on what can be stuffed into there? MultiBit uses rolling backups because there were cases where data got partially written to disk and other weirdness, so you might want to consider using the regular wallet encryption feature and then putting the encryption key into the keystore, rather than putting the entire wallet in there.

[jonas.schnelli]

BTW for the keychain - are you sure there are no size limits on what can be stuffed into there? MultiBit uses rolling backups because there were cases where data got partially written to disk and other weirdness, so you might want to consider using the regular wallet encryption feature and then putting the encryption key into the keystore, rather than putting the entire wallet in there.

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.

[hivewallet]

We'd like to keep BitcoinKit fairly open, supporting as many Bitcoin implementations as we can. That said, if you have made improvements to BitcoinKit that we can use, please do send us a pull request!

[jonas.schnelli]

We'd like to keep BitcoinKit fairly open, supporting as many Bitcoin implementations as we can. That said, if you have made improvements to BitcoinKit that we can use, please do send us a pull request!

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>

[Mike Hearn]

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.

They can create another keychain, although that's probably not very intuitive.

Using keychains has another advantage - that's usually how things like smartcards and other hardware tokens are integrated into the OS. In some cases the keychain might even be stored in hardware.

It's a neat experiment. However I think it may be less secure than the default Bitcoin encryption. Bear in mind, when you are logged in and the screen is unlocked, so is the login keychain. That means any malware on the system that can obtain root can go ahead and take the keys without any user interaction. It's not totally insecure because you still need a local root exploit, but, kernels are huge and there are surely lots of exploits remaining undiscovered.

[jonas.schnelli]

It's a neat experiment. However I think it may be less secure than the default Bitcoin encryption. Bear in mind, when you are logged in and the screen is unlocked, so is the login keychain. That means any malware on the system that can obtain root can go ahead and take the keys without any user interaction. It's not totally insecure because you still need a local root exploit, but, kernels are huge and there are surely lots of exploits remaining undiscovered.

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>

[Mike Hearn]

How would that work? The password is a constant. Google Authenticator implements OTP protocols.

I think the Trezor is the best way forward for purely local security. Third parties that risk analyze your transactions can work too, although then we run into the need for multisig transactions and (until the payment protocol becomes widespread) p2sh addresses. But Trezor exists and is real, Gary is implementing support for it in "trezorj" and I guess other wallets will follow suit.

At some point I hope we can combine trezorj and bitcoinj so all SPV wallets can benefit from Trezor support easily. But it's gonna be a lot of work to get there.

[TheButterZone]

Bear in mind, when you are logged in and the screen is unlocked, so is the login keychain.

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