Bitcoin Forum

There are handful of developers on BFL chips and over a dozen for Avalon and BitFury (then add more new chips and designs in the near future). Each hardware requires it's own modifications and the end result is several forks of the mining software, which will be a nightmare for the average miner, who is wiling to use more than one hardware and choosing the correct version for it's device(s) - that's why i would like to suggest unified communication protocol between the hardware and the mining software, so each manufacturer will need to provide a small driver for their device which the mining software can use without modifications.

I would like to invite mining software and hardware developers to discuss the inners of such protocol, which we will all benefit from.

The current version of the protocol draft can be found here:
https://docs.google.com/document/d/1-5lWeABZ3SjnUuXvTNUx2U7K10ZFhKWSiqIfnmKT7TQ/ (https://docs.google.com/document/d/1-5lWeABZ3SjnUuXvTNUx2U7K10ZFhKWSiqIfnmKT7TQ/)

For the communication method i think the best will be to use a socket communication, because it will allow connecting to remote hardware over the network too. Json can be used again as it is already present for the pools communication and configs.

The mining software (MS for short) should contain configuration options for the hardware's address and port, then user and pass just like for the pools, but the authentication is optional for the mining hardware (MH).

MH should listen to a TCP socket, but is free to communicate with the actual hardware over any other interface: USB, SPI, UART, GPIO

There should be two types of hardware - pooled at some interval and those able to request new jobs when ready.

When MS authenticates to MH - MH send's it's available options with the AuthOK response

Some options in mind:
 ShowCores - how many actual hashing chips are available - array with option to mix versions, i.e. 5 chips V1 @ 1TH and 10 chips V2 @ 50TH
 ShowClocks - working frequency for each chip
 ShowHashrates - for each chip
 ShowTemps - an array of available temperatures with option to send only values or with description
 ShowVoltages - similar to temp

If you want to make it attractive, it needs to be as simple as possible.

Forget JSON, and just use CR-LF terminated lines, for instance. Start with 2 essential commands: one to send work to the hardware, and one to get the nonces. Make the rest optional.

By keeping it simple, it is possible to implement all of it on a cheap microcontroller on a USB stick, for instance.

That was my initial idea to, but then it will be very limited in functionality and suitable for just some of the hardware, without an option for monitoring. Then i came with the idea of running the driver on the same machine (over linux socket) and leave it to the driver to communicate with the hardware, so your suggestion will be just a trimmed down driver implementation. The driver can also be implemented as a kernel module for the Linux running embedded devices (like RasPI) and provide it's socket in sys

Replacing JSON with CSV format is a good idea, as it will be easier for parsing with cheap microcontrollers with ethernet

Good luck. You're not the first to try. Every hardware manufacturer thinks they know best and either adopt the worst protocol, or invent their own, completely ignoring from the lessons and mistakes of other manufacturers, and ignoring what us devs have to say.

That's why i made this thread and would like to hear from both devs and manufacturers - who and what needs.
Let's not limit the protocol to the current hardware and if you as cgminer developer can provide the initial support for the protocol in it, i am sure the manufacturers will add more bells and whistles ... having the requirements here in advance will help both sides and most important will make the life easier for the average miner.

A am also working on a hardware and the easiest thing for me will be to add another fork and modify the code the way i want, but it will put more value in any hardware if the end user is able to update or replace to it's favorite mining software without any risk, so i am sure many manufacturers will start using it when available

The command list is IMO pretty much irrelevant.
The issues are simply USB and hardware design considerations.

How to send commands?
Seriously? People think that is an issue?

I was going to start a thread on this USB design issue a couple of weeks ago but have as yet not found to time to spend an hour or so writing up the first post.
I'll get around to it in the next week or two.

Having a different driver is no real issue.
Getting the hardware design right marks the difference between them.

TBC ...

Our USB device has a simple bulk endpoint, implementing a virtual com port. The rest is a matter of sending commands over it. What other "USB and hardware design issue" is there ?

TheSeven has a draft protocol for something like this that he might perhaps contribute.
But realistically, I don't think vendors are going to use the same protocol.
There are also practical problems due to how these devices work internally - any protocol that superset the behaviour they all need would be overly complicated and inevitably fail to address the needs of a future device.

Perhaps a binary protocol similar to stratum could work for future devices.
This requires much more memory, processing power, and testing (in theoretical worst-case scenarios, NOT simply mining bitcoin!) than current MCUs have.

Just added a link to the initial version in the first post.
The idea is to add as optional commands (at least) the temperatures and fan speeds with EngineID's just like for the GetHashrate, but if there is a preferred method for identification it should be the same for all commands, so will wait for some comments first, not to change many times one and same description.

The way I have it implemented in my USB firmware is:

work job_id block_header

The block header includes the time stamp, and the hardware is allowed to increment it. The job_id is just a number. There is no nonce range (hardware always searches full range), ntime rolling is always permitted, difficulty is set through separate command but I like your idea of including it in the work command. I don't really see a need for a nonce range. With fast hardware, the entire 32 bit nonce range is searched in just a few seconds max, and with slow hardware (what's the point ?) you can always cancel old job when a new one comes in.

To submit a valid nonce, the firmware responds with

submit nonce job_id timestamp

I have no 'needwork' command. The idea is that the host provides work quickly enough to satisfy the hardware. In case the work doesn't come quickly enough, the hardware starts incrementing the timestamp. So, if the host does not want to accept ntime rolling, it is responsible for supplying fresh work before the hardware needs it. 

I also don't have cancel job mechanism. The hardware detects that prevhash field has changed, and automatically cancels old work as quickly as it can. Of course, it doesn't hurt to include an explicit cancel command. Another option would be to include a cancel flag in the 'work' command, which is nice because when you cancel old jobs you must provide new work at the same time, otherwise the hardware has nothing to do.

The recommended and optional commands you don't need may not be implemented - that's why they are optional and so are all the [optional] parameters ... just skip them if you don't want them, but don't return a parsing error, because you don't expect them ... that's all

cscape your use case perfectly fits the current draft without the optional parameters, so this is good. Please note, that the idea is not to limit it to the current hardware only, but to be able to support future hardware and its oddities. A good example would be that BF chips do not scan the entire range, but you may have another hardware, which is able to scan the rest, so nonce range is useful option.

about "submit nonce job_id timestamp" - it will be weird to have job_id as first parameter in work, but as a second one for the result, so if you swap them it will be exactly as described.

I am thinking of having each command (except Ping/Pong) as two words in CamelCase, so I will probably replace Auth to DoAuth and Work to DoWork

If you receive an unknown command - you should simply ignore the input until the end of the line i.e. CR+LF and that's all

cancel flag with the work is not a good idea as it will limit the possibility for optional parameters if at the end or will be just one more parameter to parse at the beginning, which is 0 in 99.99% of the commands and 1 just once in ~10min

Why would you care about scanning the rest of the nonces ? It's much easier to ignore that part of the nonce space, and create some new work instead.

Let's say tomorrow we have a new hardware (single chip), which scans just half of the nonces, but is able to scan each one of them if asked ... why to calculate twice the block header (new work) and waste cpu time, when you can simply pass the same one to two chips?

With partial scans, you just introduce a lot of extra complexity. Before you can use it, you need to know if the hardware has options to set the nonce range, and you need to know the exact limitation of the hardware. For instance, the bitfury chips only scan 756/1024 of the nonce range, but the hole is not contiguous, and not user-settable. To match this limitation with other hardware is very complicated. Even if you wanted to try, it requires extra commands to obtain the information from the hardware.

To generate some new work is simple. You just call the code you already have, except a little more frequently. Sure, it wastes some CPU time, but I'd like to see that this is a problem before creating a solution.

https://en.wikipedia.org/wiki/You_aren't_gonna_need_it

@ nwoolls that was just an example and the nonce range balancing will be implemented when needed, but the protocol should allow that in a backward compatible way.
BFL firmware is able to accept/scan partial range, so by not having this as an option for the protocol would be a limitation for some mining software which decides to use it with a hardware that has it.

Why stop scanning at all? There's no benefit to ignore the rest of the nonce space.

It's a limitation of the hardware. The bitfury chips have 756 separate hashing cores, all working in parallel, with each core hardwired to search a fixed 1/1024th of the nonce space.

+1 There is actually a drawback - you may miss a valid solution. It may not be important if you only care about your shares from the pool, which are always paid, but as a solo miner I DO CARE if i miss my chance, because of that

The protocol draft is not for BF chips only and not even for current hardware only. Once again: if you don't use it - don't implement it (simply ignore) and the protocol should allow that in both cases i.e. being able to serve and keep communication even in case of unknown action or parameter.

This is just stupid. There is no need to scan the entire range since nonces are found at random.

Then why scan a range at all? Just pick one at random and stop [/sarcasm]

I don't see why that involves stopping. If anything, it would make stopping harder, as you'd have to tell the other cores to stop their part.

I am not quite sure i understand this.
BF chips are not scanning all possible nonces in the range and they also can't cancel the calculation of a job, because of a hardware limitation.
What cscape meant is that it is hard to scan the missing nonces and they may not even be in some specific range which can be passed to another hardware, not that we should stop scanning.

You switched sarcasm with stupidity. It ain't the same.

Oh, I hadn't noticed the former.

I'm confused as to what the original argument was then..
No reason to go out of your way to scan missing nonce ranges either, unless you're trying to produce work on a severely underpowered machine.
Considering how much is being invested in ASICs, it's silly to try to go super-cheap on the controller. Especially when mining rigs really should have their own full bitcoin node running. So this just reinforces that it's easier to generate more work, as cscape said.

It makes no difference whether you scan 1 full range, or 2 half ranges. The only thing that matters is how many hashes per second you can do.

Learn a little about statistics before replying again :)

What i mean is that each nonce can be a solution and skipping just one may cause you to miss a valid solution.
From https://en.bitcoin.it/wiki/Nonce (https://en.bitcoin.it/wiki/Nonce)
"Since it is believed infeasible to predict which combination of bits will result in the right hash, many different nonce values are tried"

You can't assume for example that nonce 3861865442 will not be a valid solution for some block header and if you do so then block 255679 would not have been found from BTC Guild, but someone else, some time later

Instead of 'skipping', think of it as 'replacing'. The hardware is still looking for valid solutions, just using different combinations of coinbase/timestamp/nonce. You are just as likely to find a solution if you only search half the nonce space, increment timestamp, and search the same half again in the same time as another miner searches the whole nonce space once.

Yes, i agree with that and that for low speed miners it doesn't matter if you increment timestamp or nonce, but for higher hashrates it will be more expensive to calculate new merkle root hash, once you have tried all allowed timestamps, because you have skipped some nonces, but that will be in the far future ...

It seems the general thoughts are that nonce range is useless, so i will remove it.

And remove yourself too cause you are talking nonsense.

Correct you cannot assume that ... as you cannot assume anything regarding which nonce values should be checked.

If you skip checking that last 1billion of each range, you will instead process 3/4 of 4/3 more nonce ranges ... which means you checked the same number of nonce values.

That is all that matters.
How many you check, not which ones you check.

The glaring error in your example is that you also could miss finding a block in some other work item that has a block in the bottom 3/4 of the nonce range, that you wouldn't have reached before the LP reset everything, if you were mining the full nonce range every time - since you would have only checked 3/4 as many different work items.

Both are just as valid possibilities of where a block may exist.

Neither possibility makes ANY difference to the chances of you finding a block.

OK, any comments about the protocol proposal?

It's missing several things:

• A way to know when a job has been started (and on which boards/chips) and completed (and how much of the nonce range was in fact scanned).
• A way to know which specific slave board and chip found the nonce in question.
• Access to temperature sensors.
• Control of any LEDs.
• Commands to get and/or control clock frequencies, voltages, etc.
• Some way to get error checking information/feedback, to make dynamic clocking more accurate.

Additionally, "cancel" is misspelled. IMO there is no real value for asking the device for its current hashrate.
It might be nice if the protocol were prepared to handle non-Bitcoin POW algorithms too, but this could probably be done as an extension.

Finally, if any vendors are actually willing to implement this protocol, KNK should get a BIP number assigned by gmaxwell and post the draft on the Bitcoin wiki for further review.

Thank You! This is exactly the type of feedback i was looking

The commands for get LEDs, temps and get/set clocks and voltages (listed in my second post here) will be added too, but i wanted to hear first if there is any preference for some of them to be optional or recommended for implementation.
Also i wanted to get some feedback about the EngineID idea as identification for each of them - not to replace the same text in each command later.
For the rest:

 "when a job has been started ..." - most of the MH will probably not have them implemented, but i will add them as 'Debug commands' section ... probably separate command for each one with "DebugXXX,1" for On and "DebugXXX,0" for Off

 "which specific slave board and chip found the nonce" - will add it as optional parameter for GotNonce (EngineID after timestamp)

 About error checking - good catch 10x ... the idea was that MS will verify the nonce and have it's own information, but at least for BF chips there is a need for the driver to test several nonces, so it will be double work to do that again ... maybe 'TestOK'/'TestNA'  as mandatory parameter with the returned nonce after JobID (before nonce) to indicate that the nonce was tested, so it can be hardcoded string
 For other errors like communication problems and bad nonces - also debug on/off or recommended for implementation as GotError,EngineID,ErrCode[.ErrDescr] with a list of default codes ?
 I think the later is better and maybe with status - triggered on/off or counter, but then it will be one way information only or may add GetErrors/ClearErrors ... will think a bit more on the subject and will see what i will came with

EDIT: instead of 'TestOK'/'TestNA', i think returning 0 or the share diff is a much better idea, as MS will still need it and will have to DblSha() anyway if ommited

Here we go....

The problem is that the information from the hardware is unstructured. One piece of hardware may have a board temperature sensor, another piece of hardware may have two. Or, maybe one for the board, and one for the power regulator, and maybe one integrated into each of the 512 chips. It's going to be impossible to find a common way to bind all these different kinds of properties, and find a nice way to format them all in a single line on a screen.

And the bizarre thing is that all the information about LEDs, clocks, voltages, error rates, and chip temperatures goes into the mining software, which doesn't really have a clue what to do with that. So, you need equally complicated config files to tell it that LED A needs to turn color B when temperature sensor C is >= D degrees.

Really, this information is something that only concerns the mining hardware and the user. There's no need to standardize it all, just for the benefit of the middle man who doesn't really care anyway.  A better approach would be to create a mining library that's responsible for reliable network communication, and provides a standard get/put work interface. That way, the vendor can just write his own application, communicating with it's own hardware, and just call the mining library to get fresh work and submit the results.

Rather, the driver is the non-common component here. Users don't want different applications and interfaces for each of their devices.
BFGMiner has this common driver abstraction already in place.

That depends. If the two devices are completely different in their feature set, I'd rather have two applications open, than one common one that shoehorns everything into the same format that either throws away a lot of features, or requires an overly complex specification to capture all possibilities.

That's why VersionString was introduced as required field:
 Manufacturers will implement only Work and gotNonce, because that's all they care about, but ...
 Developers and users from the community will add more and more actions and logic behind them and if at at least some of the optional commands are available as direct translation to some registers based on EngineID translation - the software will be able to manage the hardware based on the VersionString, no matter how old is the driver implementation used from the user.

or at least that's the idea and end result i am aiming at :)

Shoe horn? Lulz - got one example of that?

I mine 8 different devices on my cgminer instances ...
Icarus, AsicMinerUSB, BitBurner, Jalapeno, SC Single, BlackArrow Lancelot, BFL FPGA, ModMinerQuad
(I'm getting a Cairnsmore1 shortly also and probably a Klondike soon too)

Still can't see the shoe horn there anywhere.

OK - old idea - even BFL have that in their current SC line ...

I asked BitBurner to add that to theirs and they did.

But you've already missed something here ... when defining a 'one ring to rule them all' protocol, one version should be able to support different configurations, so version is not complete.
Again e.g. BFL SC firmware can enable and disable different options, so not only version would be required, but also a configuration response (like the BFL SC GetInfo)

So ... I'd ask directly: what is the point of a defined interface?
Best one I've seen so far is the Klondike - it doesn't handle everything needed for other boards, but for it's own purposes it's well designed.

The protocol interface is the easiest part of most devices, handling the hardware requirements is where the trouble starts :P
A different one each time is no issue at all IMO

Protocol design affects speed, and because speed is the #1 optimization criteria, it is unlikely there will ever be a standard hardware protocol.

Each ASIC has unique performance characteristics that are in part determined by what is computed off-chip (queuing, pre-compute, scheduling).

Advancements that affect what is computed off-chip may be non-obvious or complex, to the point that implementing a standard interface in the micro-controller firmware would drive up costs (i.e. more costly micro-controllers or FPGAs).

Thus, protocol complexity gets pushed to the host driver, where it lives now.

Agree and this is the reason i am using the word 'driver'.

The communication can be implemented in the microcontroller if it has enough power or on the host and only pass simple instructions to the hardware or by directly accessing internal registers.
When implemented as a kernel driver it will be able to better handle the communication to hardware when it is time sensitive and provide a socket in /var or /sys for the communication.
For Windows or when the microcontroller is powerfull enough a network socket can be used locally or remotely.

And it is exactly the opposite for the hardware people :)
So why not to separate the two, but leave a wide bridge between?

One of the problems i see is that for a manufacturer it will be difficult to follow (if at all) mining software development and to back it up with the words of ckolivas from https://bitcointalk.org/index.php?topic=228677.msg3017560#msg3017560 (https://bitcointalk.org/index.php?topic=228677.msg3017560#msg3017560)
"Oh and it's not "the current cgminer", it's the forked code based on an older version."
What about the miner in case a (security) bug is discovered in that older version several versions later, which is then fixed, but is missing the manufacturer's code and for him it will mean starting with a new fork?

By separating them, a fix or improvement in the mining software will not affect custom hardware module and the opposite an updated module will not require downloading and recompiling of new mining software.

I've always worked directly with manufacturers, often writing the code myself, so this isn't a real problem for BFGMiner.

And here comes the second problem - someone should do the same for CGminer and then someone else for EasyMiner and then for BitMinter etc.
Managing dozens of hardware and software versions is hard if not impossible and the end user (miner) will be left with no choice, but to use a specific miner and version, because of his hardware.
I hope you will agree that there is a need in such protocol at least because of this and i aim to design it as flexible as possible.

Other software is welcome to adopt a compatible driver API. BitMinter is Java, so that makes some difficulty of course.
(EasyMiner is a BFGMiner GUI)

Unfortunately, cgminer wants to reinvent the drivers themselves for no gain. It's called not-invented-here syndrome. :(

Sigh - get over it.
There are drivers that MUST use libusb ... even in your crappy clone there are libusb drivers.
How on earth is that reinventing, when all the drivers in cgminer use the same libusb.
Get a life and learn how to program intelligently rather than flipping burgers at McDonalds.

Please, stop both!
Lets not make this tread a flame war, but focus on the subject.

Not missed, but will I succeed is another question ...
"to support different configurations, so version is not complete" - trying to define it the way that even if "_list_of_supported_actions" are improperly returned there are means to correct the result based on actual responses and not expect any specific response.
"not only version would be required, but also a configuration response (like the BFL SC GetInfo)" - on my opinion all the info should be available as separate commands (and their answers), not as a bunch of text. This way, in case we change the frequency/voltage of chip X, but the driver has reset it back on it's own (as protection masure or other) - there is no need to get all info again, but ask for "GetFreq,EngineID" and get a single number back, without occupying the communication channel (and limited power MCU) for a long time.
"what is the point of a defined interface" - for an easy jump start by implementing the bare minimum and still allowing future extensions without reinventing the wheel

How is the number of jobs it needs calculated then?
I mean when we have just started and discovered X unknown devices from unknown manufacturer (otherwise we just won't ask)
Also if there are 500 chips and the hardware keeps an eye on them (to know when to pool them), so it has that detailed info - the MS may only keep the overall hashrate and ask.

What about ShaWork/ShaNonce in replacement for DoWork/GotNonce and then ScptWork/ScptNonce etc. as each may need it's own parameters?

As long as you're having the device request work, might as well have it specify how many it needs.

There are a lot of parameters for both SHA256d/scrypt/others that are currently taken forgranted.

Of more important note, I think I forgot to mention: There should probably be a single command to cancel all pending jobs ASAP, for use on block changes.

If you notice that returned timestamps are increasing too fast, send work faster.

If NeedWork is implemented - yes, there is. If not implemented, but hashrate is - the predefined fixed value may be a good start and much more easier to implement as fixed number answer.

There is - CancelJobs and it is recommended for implementation if the hardware supports it.

Example: You have 500 BF chips and you are given a single work (be it with MTime 300), but don't have nonce range division (HW limitation) and don't have NeedWork implemented. When you start you wait 1.2sec (with 200 chips idle), before sending nonces back. MS sees them coming fast and sends more, but still for 300 + a bit more until your full hashrate is reached. If GotHashrate is implemented and you return a fixed value 500x3GH - you will be given enough work from the first command.

Having either NeedWork or GotHasrate implemented will speed-up the start, while GotHasrate is easier to implement and if fully implemented gives detailed information, which the MS may not need for it's normal operation, but can be provided to a customised (for the hardware) web interface for example.

I would suggest that the best way to go about this would be to draft a document and let everyone pick it apart. Of course getting a concensus is almost impossible. When all is said and done, the important part would be getting the hardware people on board. Once they are in agreement, the software people may bitch, but they still need to support the hardware or someone else will.

Omg, this is still going?

http://imgs.xkcd.com/comics/standards.png

There are different kinds of cancellations however.  It's useful to be able to distinguish "really, don't bother, anything more you have queued will be completely worthless, cancel even if its a pipeline flush that loses work"  from "I have new work for you to start on as soon as you can without disrupting the pipeline".  ... The latter you should be able to call as fast as the communication bus allows without losing hashrate as a result.

So the first 5 seconds you run at half speed. Not a big deal over the lifetime of the equipment. And with 500 BF chips, you should have a better solution than running getwork to a single host anyway.

The draft is almost complete - there is something that bothers me with the debug errors command, which i'd like to think some more about, but the rest should be OK.
A review of the wording from a native speaker would be welcome as well as any other suggestions.
It will be great if some of the MS developers can provide a skeleton implementation for example with CPU mining or some other hardware

The fact remains, no one cares and no one will implement it, move along.

@kakobrekla are you mining hardware or mining software developer?

I have completed the 'debug errors command', which ended as InfoMsg. No changes for the rest of the document were made except fixing some spelling mistakes.

I have provided some more examples for the InfoMsg, to explain the Subsystem parameter.
Instead of having Voltage and Current - just Power is enough for both and the same for the rest of the subsystems (Temp+Fan=Cooling, Hashrate+Freq=Hashspeed) in order to limit their number

Yeah my thread is much more useful - it means: will the device mine optimally or not :)
https://bitcointalk.org/index.php?topic=294499.0

The two threads are for different aspects of the communication and implementation and so far as i can see there are no disagreements between them, but the opposite - they perfectly fit together or ... is there something that is impossible (or problematic) to do with the suggested protocol?
One of the most important things in both threads is the asynchronous workflow and i like your idea about the two communication channels ('2 pairs of end points') between MS and MH and as i was thinking not just about USB, but also for 'over the network' protocol it could be easily separated. I would prefer that it is done as an extension to the protocol for 2 TCP sockets or UDP/multicast communication later when there is a need for it.

Why add unnecessary complexity with 2 pairs of endpoints, or 2 other connections? You can simply mix various kinds data in one channel, and sort it out in the application.

On my opinion, latter when there will may be a need for a farm of network attached miners and proxies (or better name them Mining Managers), separation will be welcome.
For example MS/MM will multicast a work and each MH will only pick specific jobs (jobid%miners_total=miner_id) or process a specific mtime or nonce range, then it will multicast back it's messages, but there may be more than one MS/MM host to pick and process them in active/backup or similar jobs division (miner_ip%MM_total).
At that point in time there will be a need for inter nodes communication protocol (additions) too, but the same protocol can be used and simply extended as needed with new commands or parameters.

But why couldn't you do that over one communication channel (per MS/MH) ?

When you have many to many talking over multicast this can't be a single channel or MH will need to deal with message queue and retransmits to the backup manager etc. ... but lets think about that when the time comes - it is not part of the current protocol description.

Wouldn't it make more sense to use directed data, and send each miner only the information he needs to have ? Multicast doesn't save bandwidth, because each miner needs different work anyway.

Depends at what level you're working. If your miners are doing coinbase modifications, they could use a trick like stratum to share work.

That's true, but then they really use the exact same information, so a broadcast actually makes sense. KNK was describing a scenario where information is broadcast, but the miners only pick what's relevant to them. That's very much like your own directed traffic implementation layered over multicast.

Heh - mining using Muticast ...

I wrote/added Muticast support to cgminer a while back to supporting finding the cgminer APIs on a network.
Multicast isn't very reliable ... as is expected since it's UDP.

You'd use it for discovery, using it for sending the mining work out sounds like idle miners ...

This was just an example and we moved talking about it instead of the protocol. :)

@cscape maybe if we say 2 working threads instead of 2 communication channels it will better fit. The idea is that you don't wait for the answer of your command i.e. asynchronous communication, so MS have 1 thread that 'fires and forgets' commands and then another one which is processing the answers received data no matter if it was or was not requested and maybe even not knowing what the other thread did last summer.

Do you guys see something wrong in the proposed protocol or something that is missing, needs some changes?

I'll check out the protocol in more detail later, but one thing I'll ask right away... can you add the exact format for the work string and nonce/timestamp, with a few examples so people can test their implementation by feeding the same work and checking the results.

It's a good suggestion, thanks.
I will add an examples section at the end with a full (virtual) 'session dump', or maybe it will be better to provide several small examples or both