Topic: [ANNOUNCE] BitCoinJ v0.1, a client-mode implementation in Java (Read 19192 times)

Yes indeed. See:

https://bitcointalksearch.org/topic/rfc-requirements-for-headers-only-client-7972

In terms of scalability, could a two-tier system be developed where super users would run the main bitcoin client that would store and verify the block chain and on the second tier normal users would use a lesser version of the client such as BitCoinJ (that does not store the block chain and is only used for verification of payments?)

If bitcoin goes mainstream and takes as many transactions as Visa (thousands per second) then would Bitcoin(supernode)/BitcoinJ(node) be a solution?  Not everyone can afford racks of computers...

Now I understand why Bill has more money than Larry.

It is. Just jump in. I don't think [mike] is a full time Java coder either though you wouldn't know it.
Think of Java as C# without all the nifty stuff. When approaching a problem figure out how you'd do it without lambdas, function pointers, events, properties, valued enums, value type strings, etc. You just have objects and functions.
Then remember never to test string equality with ==, always .equals().
Now you know Java. Get cracking!

Cool, I appreciate the work you're doing. I'm not doing anything critical, just want to play around with some ideas for Bitcoin related projects. I figured going from C# to Java would be easier than C# to C++.

Yes, that is supposed to work. I haven't tested it though. John Sample has been doing some work on the networking layer and supporting multiple simultaneous peers.

Right now it's not that useful to talk to multiple peers, at least not for Android clients which is what I'm working towards. The connect/sync/disconnect model works much better. In future it'll be helpful for other stuff but there needs to be some protocol extensions first (eg finding the lowest latency peer, probing the memory pool etc).

BitCoinJ is still a building site. Be aware lots will change, in particular the wallet format and APIs will still change a fair bit. I need to do more work on block chain re-orgs as there are a few unusual cases that aren't really handled today like a reorg causing a pending tx to become invalidated by a double spend. After that I'll probably do a 0.2 release.

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.

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.

Where? Are they open source?

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.

See here:

  https://bitcointalksearch.org/topic/bitcoin-wallet-for-android-4384

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?

EDIT: just read tcatm's Javascript UI (https://bitcointalksearch.org/topic/javascript-ui-for-bitcoin-qr-code-bitcoin-uris-2673), it would be nice if some exchange like mtgox mybitcoin provide the (shared) server so users don't need to run js-remote themselves.

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.

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

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

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

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.

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?

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.

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

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

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.

thanks Mike!

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

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.

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

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

https://bitcointalksearch.org/topic/m.61658

[mike], so you really work at Google?

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

well.. there is no python implementation. there is only interface to wallet database. it would be nice to have python library for communitcation with p2p network. (although, I do not like python nor going to use it for this =))

This is supposed to be funny, right?

Thanks! This is great news. Next, we need a python implementation

Thanks, that clears it up for me.

He's not "take[n] something that's open source and put a copy right on it". Google held the copyright (as he developed it at Google) and instead of not releasing it, they chose to release it under an open source license. Most (all?) open source software will be copyrighted. I suppose [mike] could have released the client into the public domain, but I suspect Google would prefer some sort of license.

Is it? I don't understand how he can take something that's open source and put a copy right on it? I'm not a programmer so that might be the reason why. Also I'm very wary about some big company having anything to with the BitCoin clients.

I of course appreciate his effort I just don't fully understand what he is doing and what his motivations might be.

Inspiring to see you use your 20% discretion on this.

[mike] should let us know his bitcoin address so we can donate to him for spending his precious time on this.

Thanks [mike] (and Google) for using your 20% time on this project.  This is a great contribution to the Bitcoin community.

There have been a lot of questions on IRC about what, if anything, Google is doing with BitCoin. So let me clear this up.

Google staff have the ability to spend ~20% of their time on projects that interest them, as long as they are relevant or useful to the company. This policy exists to keep Google flexible and to let us explore lots of ideas at once without too much corporate overhead. I've chosen to use some of mine writing and releasing this library through the standard process we have for open sourcing our code. This means it's it has been checked by our lawyers for things like trademark/export compliance, the relevant people have approved its release and so on. This is why the code has our copyright at the top. Google benefits from and supports the open source community, and we're proud of that fact.

This is not "official" in that it does not reflect some vast corporate master plan, we are not about to start accepting BitCoins for AdWords, we have not just dropped 200GHash/sec into the network and we are not going to fork the block chain (to mention just a few of the theories I've seen floating around).

A few people have been confused by this and that's reasonable, because most companies don't give their staff as much freedom as Google does. For now, this is just me and my 20% time. I would like to see us scale up our involvement in future but there are no guarantees of that and you should think of me as just another open source contributor, who happens to be fortunate enough to get paid to work on BitCoin in (a fraction of) office hours.

lol O.o


so, uhm, are there any downloads ? ^^

Edit1:
how to get the source ?

Edit2:
Sorry, I can't brain today. I have the dumb.
->

"Copyright 2011 Google Inc." says the source code.

Could you elaborate on or clarify this statement?  Are you in any way affiliated with Google the company and are you suggesting this is a project that is officially sponsored by Google?

Do you plan to abstract your client components into the sensible 3-4 pieces?

Great to see a bitcoin implementation developed from scratch!

Google is pleased to announce the release of BitCoinJ, an implementation of the BitCoin system in Java. You can get it here under the Apache 2 license:

  http://code.google.com/p/bitcoinj/

It speaks the native p2p BitCoin protocol so does not rely on the JSON-RPC interface. It implements the "simplified payment verification" design outlined in Satoshis paper and as a result, is more suitable for mobile client developers than miners.

The library is not complete yet, but it's complete enough to send and receive coins.

BitCoinJ gives you:

• A reasonably easy to use API with full JavaDocs
• A getting started guide that takes you through one of the included ...
• Example apps, showing you how to do build a simple app with the library and how to solve Hals private key challenge.
• Unit tests and code with lots of comments. If you found it hard to understand the official implementation, try reading this one.

Please be aware of the following caveats:

• Both the API and the on-disk Wallet format will change in future releases. If you want to switch a wallet from this version of the library to another version, you'll probably have to send the coins between the two.
• The core block chain handling is not complete. It does not persist headers or block locators to disk yet, so every time you start your app it will redownload the block chain from scratch. It does not handle forks in the chain yet, this is coming in the next release.
• There are unit tests but the coverage isn't as high as I'd like. There'll be more in future.
• I'm really a C++ programmer by background so undoubtably some things could be more java-ish than they are.

I want this implementation to be as easy to understand as possible especially for people who aren't familiar with C++. If you aren't sure how to accomplish something, functionality you need isn't a part of the public API, or part of the code confuses you, let me know and I'll try to make it clearer.

The code is in Subversion and patches are welcome! Please post them either here in this forum, to the bitcoinj Google Group, or (better) using the Google Code review functionality.