This discussion has been hashed out time and time again so there is no reason to continue it here. Suffice to say, you cannot build on blocks relayed to you by the relay network any more than you can on blocks sent to you from a random peer on the p2p network.

Of course you can. It's a game of probabilities. The probability that your mining effort produces a block that ends up on the blockchain versus the probability that you produce a block that does not (orphaned, invalid, doesn't matter). If you reduce the orphan rate a little at the cost of possibly increasing the invalid rate an extremely tiny bit, then the end result improves. Mining invalid data and orphaned blocks is the same: you end up with nothing.

But even a big pool will only save a couple blocks per year, so it is perhaps not worth discussing further.

There were a few major updates and both clients should update...The java client had a rather dumb bug that prevented it from relying outgoing blocks, though it received them fine...the python client was, as is all python, so horrendously non-performant that even a network rtt for a inv->getdata->block process to be faster. With some minor effort the python client now should reliably beat network rtts (seriously python???), though I'd advise using the java client where possible.

There were a few major updates and both clients should update...The java client had a rather dumb bug that prevented it from relying outgoing blocks, though it received them fine...the python client was, as is all python, so horrendously non-performant that even a network rtt for a inv->getdata->block process to be faster. With some minor effort the python client now should reliably beat network rtts (seriously python???), though I'd advise using the java client where possible.

Upgraded, thanks. I did notice messages in both directions now instead of before on the java client.

There is now a C++ client. Those who had been using the python client should probably switch to it (its semantics are identical, it runs on Linux and under Wine, so I assume Windows) and it is much, much faster than the python client.

There is now a C++ client. Those who had been using the python client should probably switch to it (its semantics are identical, it runs on Linux and under Wine, so I assume Windows) and it is much, much faster than the python client.

Any chance you or someone else could port/compile/brew a Mac C++ version?

I tried porting and compiling myself but all the includes FUBAR'd the attempt. Or, I just need more coffee before I try again.

Been running the Java client for awhile now, but can we get the jar added to the Git Repository too alongside the other clients? It'll make keeping up-to-date much easier.

Any chance you or someone else could port/compile/brew a Mac C++ version?

I tried porting and compiling myself but all the includes FUBAR'd the attempt. Or, I just need more coffee before I try again.

Hmm, yea, I assume one or more of the socket calls isnt right? I didnt try it on any BSD. Also, it needs C++11, so if the version of clang OSX ships is particularly out-of-date it may fail there too...I'm happy to help test it if you can get me a list of compile errors.

Got it. Had to add _nodelay to the version in core/pom.xml so the RelayClient would find it after "mvn install". Strangely the tests for bitcoinj fail if you run them twice without "mvn clean". At least they did for me. But I guess that's a problem with the tests, not the library itself.

Perhaps it's an idea for pools to set up direct peering? Could shave off a little time.

Is it OK to pass new blocks directly to the RelayNodeClient instead of passing them through the local bitcoind ? Could shave off a little bit more time.

Got it. Had to add _nodelay to the version in core/pom.xml so the RelayClient would find it after "mvn install". Strangely the tests for bitcoinj fail if you run them twice without "mvn clean". At least they did for me. But I guess that's a problem with the tests, not the library itself.

Perhaps it's an idea for pools to set up direct peering? Could shave off a little time.

Is it OK to pass new blocks directly to the RelayNodeClient instead of passing them through the local bitcoind ? Could shave off a little bit more time.

If you used that branch it should already have had _nodelay added to its version number (and you should probably use that branch of your OS may hold onto data before relaying it for some time).

re: direct peering: sure, pools could do this (most already do afaiu).

Sure, no harm in passing a block out quickly, but this is also why you should treat blocks that come from the relay network identically as some arbitrary blocks you get from an unknown source on the p2p network. See, for example, the for-w branch at https://github.com/TheBlueMatt/RelayNode/tree/for-w/client which I whipped up for another poolop so that they could peer a single relay network client with a ton of local pool daemons and have it properly route blocks that come in from the relay network to their bitcoind and from one of their pool daemons to all the other pool daemons and the relay network all at once.