Stratum protocol

[konradp]

Hi,

I could not find any information about the stratum protocol. I mean, I found this:
http://mining.bitcoin.cz/stratum-mining
and consequently this:
https://docs.google.com/document/d/17zHy1SUlhgtCMbypO8cHgpWH73V5iUQKk_0rWvMqSNs/edit?hl=en_US#

But this is useless, it's way too short. In the latter document, there are mostly topics marked as "TODO".

I want to create a pool using node.js, I know there are sources on github - considering what I want to do I reduced the number of interesting projects to two - one of them doesn't work (it send badly formatted answer to client's "mining.subscribe" message) the other one just doesn't compile (I spent a day trying to, on windows and linux) - besides both are very big, there are actually full pool servers, when I only want communication with a miner.

Please tell me where can find a comprehensive information about the protocol... Is it somewhere here, on this forum maybe? From what I know, the author of the protocol was/is very active on bitcointalk.org

[eleuthria]

https://www.btcguild.com/new_protocol.php

This includes a breakdown of all the major components of stratum, with detail on what each parameter means for each method.


Obviously you're not going to get something with a guide showing you how to build a TCP socket server.  But the above page includes all the methods you need to support in order to implement a stratum server, and a description of what each piece is.  It's a purely plain-text TCP system.


EDIT:  Forgot slush copied most of my new_protocol.php page and added it to his stratum page.

From what I know, the author of the protocol was/is very active on bitcointalk.org

Slush doesn't even post on his own pool thread anymore.

[-ck]

Original discussion thread was here:

https://bitcointalk.org/index.php?topic=108533.0

There are some features that were only even documented in that thread buried in the middle.

[-ck]

Heck I think the protocol is old enough and poorly documented enough that it's time to create a new protocol fixing what we didn't get right with stratum in the first place...  Of course no pool op would adopt it since precious few even adopted the whole stratum protocol.

[eleuthria]

Heck I think the protocol is old enough and poorly documented enough that it's time to create a new protocol fixing what we didn't get right with stratum in the first place...   Of course no pool op would adopt it since precious few even adopted the whole stratum protocol.

Eh, most of them did adopt stratum (only one I can think of that didn't that still exists is Deepbit...and they hardly qualify as existing anymore).

Stratum was a needed improvement.  Getwork was just too damn inefficient for mining remotely, and ASICs sealed the deal.  I can't imagine the horror of my bandwidth bills (or the bandwidth usage for a large ASIC farm) if we still had to use getwork today.  I've actually been debating the idea of a new mining protocol over UDP, but there isn't really a "need" for it, other than the fun of developing something *slightly* more efficient [though a pain in the ass for people to implement probably since UDP would require more work for error handling/lost packets vs TCP].  Would also allow for some interesting DDoS mitigation systems (anycast + multiple destination servers?).

[-ck]

Actually I didn't say stratum wasn't needed. What I'm referring to is some quirks or limitations with the protocol and the lack of evolution of it. It was developed at the beginning of the asic era and has never been updated.

The things about the protocol that are problematic are :
First of all almost no pool implemented reconnect due to lack of interest since it only benefits miner.
The need for a separate subscribe and auth, and then virtually every pool in existence probably ignores the password which is a hangover from the getwork to local RPC bitcoind days and worthless today.
Separation of work and difficulty was a mistake. Even now new pools get the association wrong and will spew some messages about "old difficulty" when we nutted out a workaround to that limitation in the protocol. It should never have been separate.
Not setting diff on immediate connection. Starting at diff1 in the ASIC era is completely useless.
Not having some meaningful way to track transactions without having to download them all which no pool in their right mind supports due to crazy bandwidth anyway. Heck sending the hashes of the transactions only would be more efficient if you actually did write some code to compare what bitcoind is doing to what the pool is doing.
Ignoring suggested diff.
Other things I can't remember offhand.

[os2sam]

Too bad there wasn't a viable alternative from a more active group of the Bitcoin community.

[konradp]

OK, thank you all, I'll start with reading https://bitcointalk.org/index.php?topic=108533.0 and I hope it will be simpler than analyzing thousands lines of code of open sourced pools.

[konradp]

Thanks again.

I've read entire topic and I don't quite understand one thing: very often I could read that a miner can "lose their work/shares", for example "Good pools support it (mining.reconnect), so they don't force you to throw away your shares when a disconnect happens"

I thought that as soon as a miner finds a share which is <= difficulty then it immediately sends it to the pool, so how can it "lose" shares?