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

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 ;-)

Well,  there may be several optimization targets. One is what you described to minimize the number of inputs to reduce the transaction size. Another may be to use the smallest possible inputs which increases transaction size but also reduces the number of inputs we have to track (long term optimization). And finally we could try to use the oldest inputs which would allow the network to Stub off old blocks since the only useful information we can get from it is its hash which has been confirmed.

I'm not sure yet which one is best

I strongly support removing the option from the menu, let's make it harder to find

I may actually be cutting myself here as I am a strong supporter of having large decentralized computation power, unlike the professional multi-GPU setups and pools, but overall having the option in there just turns off alot of people. The getwork interface still enables people interested in supporting the network with their computation power to just start the cpuminer or one of the GPU flavours, but at that point they'll probably have informed themselfs about how long it will take and what probabilities underly the mining process.

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

~100byte * clients /5 second

Well an X display usually starts without any interaction, but to use it you'll have to enable autologin.

Then in the SSH session you want to run the command in you have to specify the display you want to talk to by setting the DISPLAY variable.

There are two ways to do so:
The first will apply it only to yourcommand, while the second will save it into the shells environment variables, so it applies to all following commands.
Also you have to know which display you want to talk to:

• DISPLAY=:x.y will use the device y controlled by driver x
• DISPLAY=:0 is a shortcut used by ATI to indicate all devices under the fglrx driver

HTH,
cdecker

I do have a fork of the DiabloMiner to add hashrate via a JMX interface, I'm using it myself with munin. Feel free to take a look https://github.com/cdecker/DiabloMiner/tree/JMX

I will add more statistics

Edit: this is a sample from one of my machines

Ok, got it. I filed a pull request and also uploaded a branch to my repo with my JMX enabled code for 5 minute averages.

What good is the $COMPUTE? I have a problem with stripping the digit from the $DISPLAY variable, as I'm using it to turn off single cards in my setup, would be nice if there where an easy way to enable/disable single cards by specifying lists of cards on the command line. Actually come to think of it I'll add it myself and file a push request ^^

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

As pointed out by other users bitcoin:// would imply a hierarchical structure (like URLs) while bitcoin: is preferred since the Address is a first level citizen while all other parameters are optional. BTW it's not an invention of js-remote, we discussed it a long time ago, but I'm happy that they adopted it ^^

It actually is
I'm still looking into using the non-blocking IO package to avoid having a thread for each connection, making it a little bit more speedy, and less of a resource hog.
The crypto stuff is designed to be built on top using a simple event listener interface that passes the messages from one module to the others and back. I'll make it ready for GitHub tomorrow, but don't expect too much, it is after all only a translation from network to POJOs

Changing the P2P protocol is not going to happen anytime soon for the above mentioned reasons (although I would welcome it)  because it would require a transition phase for the entire network to switch. I just mentioned it because someone asked me about it.

For the pushwork patch i think you are forgetting that only because you decide to use one over the other for speed reasons doesn't do anything. You have to make the format easy to implement since the miners do have to support it. The getwork interface must be enabled anyway so if the coders of the miners don't adopt the protocol you'll not have changed anything,  except a lot of work spent in a useless interface.

I'm wondering if the split is technically possible at all since the attacker is signing the transaction with his private key, and changing the amount transferred would effectively invalidate the signature. My guess is that blacklisting the "change" is a lot easier, but also easier to trick.

A double spending attack can only be detected over time, since we need a consistent view of the state the network is in. Blocks are used to synchronize and recreate consistency.

You mean the P2P protocol? I'd already be happy using JSON, but it won't work because the whole block hashing and transaction hashing relies on the binary representation of the message itself...

I have to say that I agree with slush, after implementing the Bitcoin protocol in Java I hate binary protocols.

Encoding it in JSON would allow easier implementations since most languages have some form of understanding JSON. Compression is not needed but we might simply add another port that compresses all that goes through it (think OutputStream Chaining in Java). The size of the messages will double, yes, but as far as I'm concerned that's the only downside to using JSON.

Any PCI-E x16 risers/extenders? They would be really popular in here ^^

Great stuff, finally I can wrap my head around how mining works without having to crawl through additional stuff

I don't quite get it, how's that supposed to change anything? Could setting the DISPLAY variable be a workaround? After all I'm able to start the miner via an SSH connection which has nothing to do with the Displays at all...

Also for the second core of the 5970, I think crossfire is still turned on but I can't figure out why and how to turn it off (CPU is being bombed also, which I guess is Crossfire too).