Unified miners communication protocol

[kakobrekla]

There's no benefit to ignore the rest 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

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

[1713567479]

1713567479

[1713567479]

1713567479

[1713567479]

1713567479

[1713567479]

1713567479

[1713567479]

1713567479

[KNK]

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]

[Luke-Jr]

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.

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.

[KNK]

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.

[kakobrekla]

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]

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

[Luke-Jr]

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.

Oh, I hadn't noticed the former.

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.

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.

[cscape]

+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

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.

[kano]

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]

Learn a little about statistics before replying again

[KNK]

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

[cscape]

What i mean is that each nonce can be a solution and skipping just one may cause you to miss a valid solution.

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.

[KNK]

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.

[kakobrekla]

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.

[kano]

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

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.

[KNK]

OK, any comments about the protocol proposal?

[Luke-Jr]

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.

[KNK]

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

[cscape]

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.

[Luke-Jr]

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.

[cscape]

Users don't want different applications and interfaces for each of their devices.

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.

[KNK]

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