Introducing BitcoinKit, a Cocoa framework for building iOS and OS X Bitcoin apps

[hivewallet]

Hi everyone!

We're pleased to announce a little work that may make a few developers' lives easier.

BitcoinKit.framework is a Cocoa framework that allows developers to write Bitcoin wallet apps for Mac OS X. BitcoinKit uses bitcoinj, and serves a small and tidy API for developer use. BitcoinKit's first application is as the backbone of a new Mac wallet app called Hive.

Grab the source here:
https://github.com/hivewallet/BitcoinKit

Support is available via GitHub issues and this Bitcointalk thread.

A sample GUI app is also included:

[1714031526]

1714031526

[1714031526]

1714031526

[1714031526]

1714031526

[1714031526]

1714031526

[hivewallet]

reserved

[rme]

Interesting 

[jonas.schnelli]

Looks great.
I'm looking forward to see native non-java SPV clients. I also tried to make one of bitcoinj (GCJ),.. but seams to be very hard and not so stable (and some overhead  ).

How about the effort of adding SPV features (like Multibit)? Would mean that you work on your own network layer instead of using bitcoind's.
If you plan to create a "easy wallet", i think SPV and bloom filters would be necessary.

</jonas>

[mnyonpa]

Thank you very much for your efforts!

[hivewallet]

Hi Jonas!

Yeah we absolutely plan to do this. We're either going to end up extending some of Jeff Garzik's work or write our own SPV wallet and include it in the bundle. We were pretty frustrated with the lack of non-Java options too. :/

If you're interested in helping out, please send me a message!

Cheers!

[Mike Hearn]

Writing an entire implementation of Bitcoin (even in SPV mode) is a ton of work. You should REALLY consider just using bitcoinj and finding a way to deal with the Java aspect.

I'm looking at alternatives to GCJ for using bitcoinj from native code, like transpilation into C++, but it would be a huge shame if someone ended up rewriting all that code just to avoid writing some binding/glue code. It would result in a lot of duplication of effort that slows everyone down. JNI is ugly, but there are tools that can write binding code for you.

[hivewallet]

Writing an entire implementation of Bitcoin (even in SPV mode) is a ton of work. You should REALLY consider just using bitcoinj and finding a way to deal with the Java aspect.

I'm looking at alternatives to GCJ for using bitcoinj from native code, like transpilation into C++, but it would be a huge shame if someone ended up rewriting all that code just to avoid writing some binding/glue code. It would result in a lot of duplication of effort that slows everyone down. JNI is ugly, but there are tools that can write binding code for you.

You're right, and we're well aware of this, but we're looking for a clean long-term solution. I'd say we're far from against trying to make bitcoinj work, but our resistance to that approach has more to do with the lack of a guaranteed JVM in Mac OS X. We could simply include it in the application package, but that is far indeed from ideal.

As we were saying on bitcoin-development, the idea of a transpilation sounds very interesting. No one on our side has ever tried to do something like that. If we can encourage you to put on your lab suit and give it a whirl, well... It would certainly not go unappreciated!

[Jaxkr]

The text animation on grabhive.com is really obnoxious. Personally, I'd recommend the text fades in one line at a time.

[hivewallet]

The text animation on grabhive.com is really obnoxious. Personally, I'd recommend the text fades in one line at a time.

I'm sorry that you don't like it. It will be gone soon enough though. :-)

[hivewallet]

Just a quick note to say that released Tor.framework, which works with this, here:

https://bitcointalk.org/index.php?topic=264767

[hivewallet]

First non-Hive app to use BitcoinKit is released! Enter MacWallet! Congrats Jonas!

[hivewallet]

The BitcoinKit repo URL has been changed to the following:
https://github.com/hivewallet/BitcoinKit

[jsuder]

Small progress update - I've been doing some backend changes & fixes in Hive lately, so that naturally means BitcoinKit changes & fixes too:

1) Exception handling:
- all Java exceptions thrown during calls from the Cocoa side will be wrapped in Cocoa exceptions and thrown back to the caller
- exceptions on Java background threads (at least those handled by bitcoinj's uncaughtExceptionHandler) will also be wrapped in NSException and either passed to a provided exception handler block, or thrown on the main thread

2) Added walletDebuggingInfo method which calls bitcoinj's wallet.toString(), this returns a kinda-human-readable block of text with various info about the wallet.
3) Added estimatedBalance property which includes total balance available now + that which is currently blocked because of unconfirmed transactions. (Pending balance = estimatedBalance – balance)
4) BitcoinKit now presents itself as "BitcoinJKit 0.9" when connecting to other peers (I'll add a method to set a custom app-specific user agent later).
5) Minor fixes to transaction dictionary data returned from HIBitcoinManager methods (e.g. date formats).
6) Updated bitcoinj to v. 0.10.2 (previous version was before 0.10).

[Mike Hearn]

Nice! It's great to see BitcoinKit maturing like that.

[jsuder]

Hi,

we're still working hard on adding new features to Hive and BitcoinKit. Here's what changed in BitcoinKit in the last month:

• we're working on adding encryption support now: you can create a wallet with a password or encrypt an existing one, and pass the password when sending coins (this isn't finished yet though)
• there are now logging macros like HILogError() that you can use to redirect logs to a chosen logging framework (e.g. CocoaLumberjack), and the logs from Java are integrated with this too
• bitcoinj is updated to 0.10.3 - this fixes a bug that could cause a transaction to never be sent
• we've removed the bitcoind backend since we weren't supporting it anymore anyway
• transaction fee is now added, not subtracted from the amount (so 0.3 mBTC is sent as 0.3+0.1 instead of 0.2+0.1)
• the demo app (https://github.com/hivewallet/BitcoinKit/tree/master/DemoApp) should now build properly again
• we've fixed an issue that could result in overwriting a wallet, and another that returned incorrect balance if it was more than 21BTC
• improvements to error handling (a lot of methods now accept an NSError** argument)
• it should be easier to debug the Java parts with a Java debugger (https://github.com/hivewallet/BitcoinKit/commit/2c45b54)

If you're working on an app that uses our library, please let us know!

[jsuder]

Monthly BitcoinKit update:

• you can now back up the wallet with exportWalletTo:error:
• you can ask BitcoinKit for the date of last change in the wallet (that affects the keys, i.e. changing the password) - we use this to check if backup is up to date
• fixed the process of rebuilding the wallet if the chain file is removed, and added a way to start that manually with resetBlockchain:
• fixed a lot of issues that could result in a transaction status not being updated or transaction not appearing in the UI
• switched to latest bitcoinj (0.11-SNAPSHOT)

[jsuder]

Hi there,

lots of updates in BitcoinKit since my last post:

• the biggest thing is BIP70 Payment Protocol support (both from bitcoin: URIs and from local .bitcoinpaymentrequest files)
• we've also cleaned up the Maven configuration for the Java build; it's now easy to update bitcoinj to the latest version, right now we're building BitcoinKit with bitcoinj 0.11.2 (will be updated to 0.11.3 soon)
• added support for signing messages with the private key
• added support for checkpoint files for super fast initial sync
• the fee is now calculated based on entered amount, not estimated to be always 0.1 mBTC
• method for checking if the entered password is correct
• methods for checking syncing status and number of connected peers
• error handling improvements - e.g. added error codes for sending dust or locked chain file
• fixed some problems with JSON that resulted in empty transaction data being returned e.g. for multisig addresses
• transaction data no longer includes "from" addresses - it's not possible to detect it with 100% confidence, and it would be dangerous to show it if it's incorrect
• converted all code to ARC

Let us know if you're using BitcoinKit in your app!

Also: Mike Hearn is working on integrating a different JVM that can be bundled in the app, so in the future it should be possible to drop requirement for a JRE installed in the system.