[ANN] Bitcoind Client for Java

[johba]

Hi there!

I recently got frustrated with the available client apis for java and wrote my own: https://github.com/johannbarbie/BitcoindClient4J

It supports listeners for notifications and I'm working on multi-sig transactions currently.

Check it out and give me some feedback.

[1715410726]

1715410726

[1715410726]

1715410726

[Mike Hearn]

Cool!

You could try making the library start bitcoind itself given a path to it. That way if you can make it select ports automatically in case 4001 is already used by something.

I'm curious if you tried bitcoinj beforehand (if that's what frustrated you)? Feedback is always welcome if so.

[johba]

You could try making the library start bitcoind itself given a path to it. That way if you can make it select ports automatically in case 4001 is already used by something.

That's a great idea, thank you

I'm curious if you tried bitcoinj beforehand (if that's what frustrated you)? Feedback is always welcome if so.

I was aware of bitcoinj beforehand, but didn't consider it as bitcoind client library. Is it possible to manage a wallet with bitcoinj and have bitcoind just relay transactions?

Well, let me explain the context quickly. I'm bilding an SMS wallet as described here: https://bitcointalk.org/index.php?topic=300855.0 , so basically a hosted wallet with many users. I was looking at the different bitcoin implementations: BitcoinJ, BitcoinD, Bits Of Proof.

• Bitcoinj seems aimed at mobile, and somewhere I read that it wouldn't scale well with many addresses, so I immediately dropped it.
  
• B.o.P. looked great, but I couldn't find the wallet implementation, It seems not to be open sourced.

So I went ahead with bitcoind. The frustrating thing was merely that java implementations of talking to bitcoind I could find open source were to cluttered, almost all of them trying to reinvent json-rpc.
By writing one single java interface file and hooking it up with google's jsonrpc4j I had basic functionality up and running.

[Mike Hearn]

Yes bitcoinj gives you a wallet and you can just attach it to a local bitcoind, then security level is the same.

But also yeah, for hosted wallets bitcoinj isn't going to do a good job. Lots of people want to run hosted wallets, although I think that's a rather dangerous approach, but nobody ever contributes back the work needed to run it well.

The bitcoind wallet doesn't scale all that brilliantly either by the way. I think most large hosted wallet providers end up writing their own wallet code anyway. Improving bitcoinj is certainly one way to go about doing that.

[johba]

Mike, thx for the advice! I'll focus my attention on bitcoinj for the future. For prototype functionality bitcoind is really nice and easy though. Especially the account functionality saved me a lot of dev effort. I am getting more aware of the limitations now.

Of course I see that hosted wallets undermine the very concept of bitcoin. The intention with this one is not offering a seemingly secure service, but lowering the barrier of entry for non-tech-savy or offline users by use of SMS. And once aware of bitcoin, they should see the need to run a wallet themselves.

One thing I tripped over when implementing the service is identifying recipients. Entering an bitcoin address into a text message is really impractical (i'm working on receiving mms with pictures on qr codes). But I really wish to be able to send payments to email addresses. I briefly searched the forum for webfinger, but couldn't find anything. The BIP list merely contains the uri scheme. What's your opinion on using webfinger for payment identity: http://www.onebigfluke.com/2013/06/bootstrapping-webfinger-with-webfist.html

[Mike Hearn]

Well it's hard because you need a fresh address each time ideally. For SMS wouldn't you want to send to phone numbers instead?

You could look into something called identity based encryption. For your purposes it might work.

[johba]

Well it's hard because you need a fresh address each time ideally. For SMS wouldn't you want to send to phone numbers instead?

You could look into something called identity based encryption. For your purposes it might work.

If I got you right, IBE could help generate public keys from IDs. That's really cool, because the public key comes to live before the receiver(in blockchain terms) actually generates the private key to receive the ownership. But IBE has this inherent key escrow. The Private Key Generator needs to be trusted. So I've checked the variants that eliminate this trust:

• certificate-based encryption (needs to distribute a public key)
• secure key issuing cryptography (multiple third parties, requires trust they don't cooperate)
• certificateless cryptography (cool, but needs to distribute a user-generated public key)

So IBE and the second variants introduce a trust issue, while first and third variant defeat the purpose of what IBE solves in term of public key distribution.

I had an idea where I would still use WebFinger to distribute the pubkey in 3rd variant, but then instead of just using the ID like email or phone number I would attach a timestamp of the transaction. By this still dealing with the distribution problem, but solving the issue that the address should be fresh each time.

So here is CL-PKC(variant 3) with my use-case:

• KGC chooses master public key mpk and master secret msk.
• Bob generates a secret value x_ID(Bob) and a corresponding public key pk_ID(Bob)
• Alice takes ID(Bob), pk_ID(Bob) and mpk, combines it into a new public key, and uses it to publish at transaction on the blockchain.
• Bob asks KGC for partial private key d_ID(Bob), which KGC computes from ID(Bob) and msk, and delivers it securely to Bob.
• Bob combines d_ID(Bob) and x_ID(Bob) to produce the full private key sk_ID(Bob) and now can spend the coins on the blockchain.

I took most of it from here: http://www.isg.rhul.ac.uk/~kp/certlessI.pdf

Unfortunately it turns out that pk_ID(Bob) which Bobs needs to publish derives from x_ID(Bob). So I can not modify ID to generate new addresses every time.


Or did I apply IBE for the wrong use-case all together?