[ANNOUNCE] BitCoinJ v0.1, a client-mode implementation in Java

[chromicant]

Thank you [mike] for this! Great work!

I'm browsing the code right now... You implemented all the crypto stuff on your own?? Wow... is bitcoin choice of cryptographic functions so particular that you couldn't find no Java library for it? Anyway, all my respects to you, sir! All those numbers and binary operations make me dizzy just to look at....

It's Bouncy Castle. If you want some crypto, and want it in Java...it's where I'd start.

[Mike Hearn]

The code under the bouncycastle package is just a renamed version of the lightweight bouncy castle library, so no, I didn't implement all that myself. It's renamed to avoid conflicts on Android.

It's only the stuff under the com.google.bitcoin package that is new.

[TiagoTiago]

Are there any python clients out there that are fully functional though?

[em3rgentOrdr]

thanks Mike!

[dsg]

Are there any python clients out there that are fully functional though?

There are several implementations of the network node code, but to my knowledge none implementing wallet handling. If anyone knows better, please let me know.

[RodeoX]

Just a thank you for choosing Bitcoin for your 20% project. I hope Google sees the possibilities also.

[hogofwar]

Just to make sure, is it supposed to need the official bitcoin client running when running the example to download blocks?

[Mike Hearn]

The PingService example uses localhost so yes, it expects a local C++ node running.

You can point it at some other node if you like, for instance one of the nodes on the wiki fallback page. I haven't written the code to discover new nodes, record their addresses etc yet, so you have to provide it with an IP address to start with.

[alkor]

Are there any plans to add a GUI to bitcoinj so that we ordinary mortals can test it as a replacement for the official Bitcoin client?

[Mike Hearn]

Maybe later. For now there is plenty of work to do in supporting the needs of Goonies Android client.

I'm not sure if it'd be better to build a new GUI on top of BitCoinJ and compete with the C++ client directly, or just finish implementing client mode in Satoshis code and continue recommending that to new users.

My gut feeling is that a really well done client-mode in the C++ node would be better for now, because it could theoretically start out in client mode and then upgrade itself to a supernode (with a full copy of the chain) if it detected it had sufficient spare computing power and inbound connectivity. This would be best for the networks health as it'd ensure a constant supply of nodes that are verifying transactions properly. If most users ended up on an alternative BitCoinJ based client, that wouldn't happen.

But it's also a lot more work which right now nobody is doing. And I think we all accept/hope that in the future, people who just want to buy and sell things won't be able to run supernodes anyway because the transaction rate will be high enough that it'll become a major burden. Only miners and the biggest/more sophisticated merchants will do it. In that case having a One True Client that switches between modes might just become a liability as people with good computers install it and then a few days later wonder why their hard disk is constantly thrashing and they see giant spikes in CPU usage from this simple bit of payments software.

Another factor is that the burden of maintaining cross platform GUI code is pretty high. Satoshis code is lacking a lot of simple features (like recurring payments) that aren't hard to do, but nobody does them because working with wxWidgets is painful and compiling on all 3 supported platforms especially awkward. A Java SWT/Swing based client would be open to more developers, and you could make a change on one platform that runs on others you may not have access to with a reasonable degree of confidence.

On the other hand Java desktop apps have a reputation for sucking, partly because historically Swing and the JVM were very bad at doing GUIs, partly because Java is a resource pig and partly because Oracles JRE is annoying as hell and constantly bugs you to upgrade.

So there are pros and cons, I haven't thought about it much beyond that.

[xf2_org]

+1 to what [mike] said, from this dev

(this is 'jgarzik', posting under a new nick)

[bitcool]

[mike], great job. Since it's Java and you hinted the code is Android compatible -- is there a plan to roll out a mobile client?  -- not necessarily a p2p client though -- That is one thing I am eager to see. 

[bitcool]

[mike], great job. Since it's Java and you hinted the code is Android compatible -- is there a plan to roll out a mobile client?  -- not necessarily a p2p client though -- That is one thing I am eager to see.  

Never mind, just read the project home, it says:

"The project aims to be easier to understand than the C++ implementation, and be suitable for usage on constrained devices such as mobile phones."

"BitCoinJ implements (or rather, will implement) the "simplified payment verification" mode of Satoshis paper. It does not store a full copy of the block chain, rather, it stores what it needs in order to verify transactions with the aid of an untrusted peer node."

This is great if it can be achieved on mobile devices with good performance, I have some doubt though.

[bitcool]

[mike], great job. Since it's Java and you hinted the code is Android compatible -- is there a plan to roll out a mobile client?  -- not necessarily a p2p client though -- That is one thing I am eager to see.  

Never mind, just read the project home, it says:

"The project aims to be easier to understand than the C++ implementation, and be suitable for usage on constrained devices such as mobile phones."

"BitCoinJ implements (or rather, will implement) the "simplified payment verification" mode of Satoshis paper. It does not store a full copy of the block chain, rather, it stores what it needs in order to verify transactions with the aid of an untrusted peer node."

This is great if it can be achieved on mobile devices with good performance, I have some doubt though.

EDIT: just read tcatm's Javascript UI (http://bitcointalk.org/index.php?topic=2673.0), it would be nice if some exchange like mtgox mybitcoin provide the (shared) server so users don't need to run js-remote themselves.

[em3rgentOrdr]

What is "Goonies android client"?  I was just about to take your java implementation and port it to android.  Is someone else already working on this?

[Mike Hearn]

See here:

  http://bitcointalk.org/index.php?topic=4384.0

[BitterTea]

Is it possible to create a Peer without a Wallet? It seems like you need a Wallet to create a BlockChain and a BlockChain to create a Peer.

[wumpus]

There are presently at least 2 independent Python p2p implementations...

Where? Are they open source?

[Mike Hearn]

Is it possible to create a Peer without a Wallet? It seems like you need a Wallet to create a BlockChain and a BlockChain to create a Peer.

You need a wallet. If you don't care about that just create a new one for every run of your program, "new Wallet()" directly passed to the constructor works fine.

I might make providing the object optional in future. Obviously you can't send/receive coins without a wallet so that use case is only for, as Satoshi might say, intrepid programmers who want to do something a bit different.

[BitterTea]

Ah, that makes sense. I'm newish to Java, and I've only been looking over the code the past few days, but can multiple Peers share the same BlockChain/Wallet? I was trying to figure out how one might manage multiple connections, but I wasn't sure if multiple instances of a Peer would sync on the same BlockChain.