jonas.schnelli



Offline



Activity: 66

Merit: 10



bitcoin core contributor







MemberActivity: 66Merit: 10bitcoin core contributor MacWallet - another bitcoin wallet app October 07, 2013, 03:54:30 PM

Last edit: November 06, 2013, 11:57:26 AM by jonas.schnelli #1

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



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



Every feedback and every testing effort will help MacWallet to get more stable.

Report issues here:



Some screenhots:















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.Thanks to the Hive developers (), 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 interfaceIt'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 Report issues here: https://github.com/MacWallet/MacWallet/issues Some screenhots:

Mike Hearn



Offline



Activity: 1526

Merit: 1008







LegendaryActivity: 1526Merit: 1008 Re: MacWallet - another bitcoin wallet app October 07, 2013, 07:21:06 PM #5



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

jonas.schnelli



Offline



Activity: 66

Merit: 10



bitcoin core contributor







MemberActivity: 66Merit: 10bitcoin core contributor Re: MacWallet - another bitcoin wallet app October 08, 2013, 09:54:12 AM #11 Quote from: Mike Hearn on October 08, 2013, 09:03:10 AM 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 (

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.

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



Offline



Activity: 1526

Merit: 1008







LegendaryActivity: 1526Merit: 1008 Re: MacWallet - another bitcoin wallet app October 08, 2013, 10:08:18 AM #13 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



Offline



Activity: 66

Merit: 10



bitcoin core contributor







MemberActivity: 66Merit: 10bitcoin core contributor Re: MacWallet - another bitcoin wallet app October 08, 2013, 10:46:29 AM #14 Quote from: Mike Hearn on October 08, 2013, 10:08:18 AM 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. 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.

jonas.schnelli



Offline



Activity: 66

Merit: 10



bitcoin core contributor







MemberActivity: 66Merit: 10bitcoin core contributor Re: MacWallet - another bitcoin wallet app October 08, 2013, 12:53:54 PM #16 Quote from: grabhive on October 08, 2013, 10:55:32 AM 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> 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.

Mike Hearn



Offline



Activity: 1526

Merit: 1008







LegendaryActivity: 1526Merit: 1008 Re: MacWallet - another bitcoin wallet app October 08, 2013, 02:17:28 PM #17 Quote from: jonas.schnelli on October 08, 2013, 10:46:29 AM 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. 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



Offline



Activity: 66

Merit: 10



bitcoin core contributor







MemberActivity: 66Merit: 10bitcoin core contributor Re: MacWallet - another bitcoin wallet app October 08, 2013, 02:53:05 PM #18 Quote from: Mike Hearn on October 08, 2013, 02:17:28 PM 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> 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)?