Topic: BitDroid Network implementation opensourced (Read 4589 times)

I think I got the Non-Blocking Reactor to work nicely. Just testing it in two instances:

• Long term test with 250 open connections (running for the last 24 hours), without a single hitch
• Speed and memory testing: this is actually on an emulated android with 8 open connections

I'm quite pleased that the android version only takes 4 MB of Heap to run, and I will try to get it down even further to make room for the crypto stuff. Next thing for the reactor are scheduled tasks and repeating tasks (similar to twisted's Deferred).

Just starting to build the wallet itself, and we got our own little page (you might have guessed it from the package names): http://bitdroid.net (as soon as my ISP finishes the scheduled maintenance which was supposed to end 3 hours ago...).

First goal: identify my own transactions and store possible inputs for future transactions.

Just a heads up: this is not production ready code (hopefully it will be soon^^)
The API is still changing frequently, but that is also good since it allows you to get to help me design it, just tell me what you'd like and I will consider adding it

Edit: the code runs perfectly fine on my Android Wildfire with 50+ connections, no noticeable slowdown Looking forward to implementing the block storage ^^

Great! I am TD on that channel. Say hi some time.

Oh yea, I've been watching that thread....

I've been known to hang out in the #bitcoin-dev channel. I think the individual components are coming together nicely, just need to glue them together.

At some point, I want to get my Ruby REST client-C2DM bridge cleaned up and talking with the monitor patches to bitcoind. Course, Google also needs to get that service out of beta ASAP...

Hi chromicant,

There is LOTS of interest in an Android client. Hopefully soon we'll have a codebase we can all focus our efforts around.

You may wish to review this thread:

https://bitcointalksearch.org/topic/mobile-client-design-ideas-3017

Will wait with baited breath...

As for the crypto, I don't have any problems with that, I'm quite at home with that. Where I'm on the fence is with my Android implementation.

There's two ways to go with it, as I see it:

1) Use the network implementation here and push the transactions out that way. Getting transactions you can either poll to snarf blocks (to save battery), or use the patches for bitcoind to use REST to my Ruby app to push transaction notification to my device.

2) Stick to JSON to control bitcoind and transactions. Poll the bitcoind instance to get updates to transaction state.

(2) is definitely the simpler option, and can work with everything out the box. (1) is by far the more elegant solution IMHO. (1) also has the bonus that a stripped down bitcoind can be created and shared among a bunch of people, basically making said bitcoind daemon a proxy to the bitcoin network.

So far, I haven't gotten past the sketching phase for the Android app (I got distracted trying to port jgarzik's cpuminer to ARM NEON with some success), so I haven't really started to write any code of note.

[ObGetThreadBackOnTrack]
How hard would it be to implement the getblocks and getdata messages?

I would love that ^^
If [mike] allows I'll write an adapter for his code to be connected to my protocol layer

Peanut butter, meet chocolate

Is there any chance of interoperability between these libraries?

Great to see this be released!

I finally got all the approvals I need to open source my implementation. I'm hoping to have it out by next week, though it's not really complete. It will include examples of how to create transactions like you want.

Note that if you want to do serious protocol level stuff like crawling the network, Christians implementation is still better than mine. I focussed on the crypto part, currently you have to specify the IP address to connect to manually.

Well since I've not implemented the crypto part yet you'd have to create a transaction object by specifying inputs, outputs and scripts and then just submit it using sendMessage in the bitcounNetwork implementation you chose. More on that tomorrow ;-)

Excellent work. Trying to wrap my head around how to send a message, specifically a transaction. Any pointers on how to do so?

Some good news: I have implemented the non-blocking IO reactor, which should allow us to handle all connections in a single thread. That frees up a lot of resources and should be performing nicely.

As for examples on how to use the library see https://gist.github.com/839394 and https://gist.github.com/839395 (the first using a single BitcoinClientSocket, while the second one uses the NonBlockingBitcoinNetwork to do the same).

BTW: welcome to the forum dabron, hope to see your implementation some time ^^

Thanks for releasing this code. I am still in the process of learning about the Bitcoin protocol, so this will help me out a lot. This summer I am planning to write an Android app for my master's report. It will use near-field communication to send bitcoins from one device to another. I plan to also open-source what I develop.

I love the idea! I am in the process of writing a Java program for my thesis right now... unfortunately I had to pick the subject in August 2010 and I found out about Bitcoin in September 2010... so I ended up doing some stupid multi-timer application instead of doing something related to Bitcoin! :/

Hooray for Java !

I have been planning to do this for a long time and finally I decided I had to opensource my Bitcoin network protocol implementation. I was hoping to have it ready and robust by the time I'd release it into the open but my master thesis is about to start and I still have to complete some papers I've been writing for quiet some time, so I'm forced to release an unfinished implementation.

My goal was to create a stable and versatile implementation of the P2P protocol the clients use to communicate with each other in Java. This is not a simple frontend but an attempt to create a clean room implementation of the actual protocol! I know there are quiet a few people out there trying to do exactly the same, and I would love to get them on board with this project.

The need for an alternative client is there, especially if we want to get Bitcoin to go mobile, as an Android app, or simply because we don't want to put all eggs in one basket (right now, should a bug be discovered in the Mainline client the whole network can be taken down by a single attacker).

As for what is implemented:

• Client can connect to other clients
• A connection can be maintained (proper handshake, pinging, ...)
• All messages except getblocks and getdata have been implemented and work correctly
• The code can notify any number of listeners about incoming messages and messages can be sent back
• 70%+ code coverage with our unit tests!

What will soon follow:

• A simple driver to keep a pool of connections alive
• Switch to Non-blocking IO in order to avoid having threads idling waiting for incoming messages
• More unit tests
• Less ugliness, more coolness

What will not be implemented in the network part:

• Crypto stuff: I wanted to keep the network implementation as small as possible, and cool things can be done even without the crypto stuff (network crawling, relaying messages, ...) so I decided to move the crypto stuff out of this module and implement it as a listener that will plug into the network core.
• Block storage: again this is to keep things simple, and it would be cool to have multiple implementations of this (flat file/SQL storage, keep everything/keep only inputs for my transaction, ...)

Using it
As I said, it is a library and not a standalone program. In order to use it your program has to provide an implementation of the BitcoinEventListener interface which allows the library to notify your code about messages from the network, and also allow your program to send messages back. For an example about how to use it see BitcoinClientDriver which is the code that does the handshake and keeps the connection alive.

Coding
As I said, I'm hoping to get more people on board with this. The code is released under the Apache License, which should make it possible for you to reuse it. I tried to keep the number of dependencies as low as possible (come to think of it, the only dependency is SLF4J, which allows you to plug in any logging facility you want).

The code is on GitHub (https://github.com/cdecker/BitDroid-Network), feel free to fork it, I'm only asking you to help me improve it by contributing changes back to the me (just send a pull request and I'll merge it in if it's a reasonable change).

I'm using Maven2 as a build tool, to get started check out the code and run mvn package and it'll build.

Under src/test/resources we have 24 hours worth of network dump split into single messages, they are used in the unit tests, which I'm proud to say cover most of the code. Should you find a bug please create a unit test that illustrates the problem.

And now start flaming about the quality of the code