[ANN] Stratum mining protocol - ASIC ready

[DrHaribo]

To get the most accurate ntime you can roll it forward by 1 every second. Then you can reuse all your merkleroots again.

Or if you insist, like kano, then you can stick with the old ntime value and throw the merkletrees away and recreate them again for no reason.
But please keep in mind that such an inaccurate ntime is bad for Bitcoin.

[1714828076]

1714828076

[1714828076]

1714828076

[1714828076]

1714828076

[makomk]

While this is true, I think a better rebuttal would be:
An average piece of work would only take ~10 SHA256 hashes to rebuild the merkleroot.  The # of transactions in a block has to double to require each extra hash to build the merkleroot.  Those ~10 SHA256 hashes produce 4.2 billion hashes worth of work.  So if the chip implements nonce rolling internally, it would only decrease effective speed by ~0.000000238%.

In practice it's unlikely that nonce rolling will be implemented on the ASIC itself. It'd require much more complicated control logic than the actual mining core itself, and also enough fast RAM to store the merkle branch and potentially quite a large chunk of the coinbase transaction. Currently, people are looking at doing it on a seperate microcontroller which is obviously going to be a lot slower and somewhat memory-constrained.

To get the most accurate ntime you can roll it forward by 1 every second. Then you can reuse all your merkleroots again.

That requires actually storing them all somewhere.

[kano]

To get the most accurate ntime you can roll it forward by 1 every second. Then you can reuse all your merkleroots again.

Or if you insist, like kano, then you can stick with the old ntime value and throw the merkletrees away and recreate them again for no reason.
But please keep in mind that such an inaccurate ntime is bad for Bitcoin.

... I wonder where I said that

[DrHaribo]

To get the most accurate ntime you can roll it forward by 1 every second. Then you can reuse all your merkleroots again.

That requires actually storing them all somewhere.

You have to store the merkleroot and the extranonce2 bytes at least until you submit all proofs of work based on them. After that you could free them, but you will need to reallocate that memory to create new work in less than 1 second. It's better to keep those few bytes of memory sitting there until the server gives you new work, rather than constantly free and reallocate those tiny memory fragments.

Or if you insist, like kano, then you can stick with the old ntime value and throw the merkletrees away and recreate them again for no reason.
But please keep in mind that such an inaccurate ntime is bad for Bitcoin.

... I wonder where I said that

In the BitMinter thread I suggested rolling ntime in sync with the clock and reusing work, but you protested vehemently against any modification to ntime. And cgminer does indeed stick with the old (now inaccurate) ntime it got from the server. Yet you also said an inaccurate ntime is bad.

Riddle me this: How can a clock never change and yet be accurate?

[kano]

...

Or if you insist, like kano, then you can stick with the old ntime value and throw the merkletrees away and recreate them again for no reason.
But please keep in mind that such an inaccurate ntime is bad for Bitcoin.

... I wonder where I said that

In the BitMinter thread I suggested rolling ntime in sync with the clock and reusing work, but you protested vehemently against any modification to ntime. And cgminer does indeed stick with the old (now inaccurate) ntime it got from the server. Yet you also said an inaccurate ntime is bad.

Riddle me this: How can a clock never change and yet be accurate?

Quote me

[DrHaribo]

Maybe I misunderstood you, kano.

So are you saying that an inaccurate ntime is fine and you must never touch ntime (let's call it the "magic token") after you got it from bitcoind?

Or are you saying that inaccurate ntime is harmful for bitcoin? Let's call it the "kano attack". By that logic would you also say that cgminer is becoming just another miner that people should avoid using? Maybe look at bfgminer or poclbm in hope that they are less harmful to Bitcoin? I mean you often recommend people to not use other products and services for much less serious reasons. What if your own product can destroy Bitcoin?

There's always the third option. You know that I'm right, you just like to write a lot of words.

[kano]

Maybe I misunderstood you, kano.

So are you saying that an inaccurate ntime is fine and you must never touch ntime (let's call it the "magic token") after you got it from bitcoind?

Or are you saying that inaccurate ntime is harmful for bitcoin? Let's call it the "kano attack". By that logic would you also say that cgminer is becoming just another miner that people should avoid using? Maybe look at bfgminer or poclbm in hope that they are less harmful to Bitcoin? I mean you often recommend people to not use other products and services for much less serious reasons. What if your own product can destroy Bitcoin?

There's always the third option. You know that I'm right, you just like to write a lot of words.

No, I'm saying your an idiot. I've never said that ntime shouldn't be changed.
You even pointed out your stupidity yourself above:

...
Riddle me this: How can a clock never change and yet be accurate?

Which of course is stupid.

The problem with roll-n-time is that the block's ntime is regularly wrong
I run a diff report in php on my computer often and it shows the block times ... and in red where they go back in time ... often
The problem when ASIC comes along is that they will be even more wrong with roll-n-time.
(and there is the risk of valid block orphans due to this) <- I guess you don't know about this one then ...............

I have also argued that vardiff and roll-n-time works with ASIC.
They do work, even up to 500GH/s for 60 seconds worth or work.
Doesn't mean I don't think that roll-n-time is bad.
But of course it will be necessary for those crappy miners and pools that don't support stratum or gbt (like ...)

I've no idea where you even got the stupid idea that cgminer doesn't touch the ntime.
With GetWork:
If a pool wants ntime rolling, then cgminer rolls it (up to 7000). That's simply using the GetWork rules provided by the pool.
Yep it's not good to use that pool - and with ASIC it could be problematic due to the bitcoind rules regarding block timestamps.
Roll-n-time has been around for a long time - no idea why you would think that cgminer wouldn't use it - I guess you should check things before making stupid statements.

If a pool doesn't want ntime rolling it, then it doesn't change it - since it can't of course ... and anyone who tries to mine on such a GetWork pool with a 50GH/s ASIC device is gonna get a rude shock.

[-ck]

DrHaribo means cgminer doesn't change the time stamp with stratum, which it doesn't since I didn't see the point. Since most pools update stratum structures with a push every 30 seconds, the time can be out by 30 seconds. Compare with ntime rolling where it can be out by 2 hours... I didn't see much point in trying hard to get the time correct to within 1 second.

[kano]

DrHaribo means cgminer doesn't change the time stamp with stratum, which it doesn't since I didn't see the point. Since most pools update stratum structures with a push every 30 seconds, the time can be out by 30 seconds. Compare with ntime rolling where it can be out by 2 hours... I didn't see much point in trying hard to get the time correct to within 1 second.

Then I've no idea where his coming from coz that has nothing to do with me
(though it is a rather pointless argument on his behalf anyway as you pointed out)

[DrHaribo]

What ckolivas said. My point is that ntime doesn't need to be exact to the second. We could require every miner to own their own atomic clock, but why bother.

Stratum does not need ntime rolling because a single stratum work unit is 4.2 billion times larger than a standard getwork unit (by default, it can be increased and the spec supports it very easily).  However, Stratum also does support ntime rolling, the official spec is that ntime should not be increased faster than real-time.

Maybe I missed something, but from what I can see the Stratum spec only says you get an ntime from the server and you send one back. I can't find where it says how you should treat this value?

[Askit2]

What ckolivas said. My point is that ntime doesn't need to be exact to the second. We could require every miner to own their own atomic clock, but why bother.

Stratum does not need ntime rolling because a single stratum work unit is 4.2 billion times larger than a standard getwork unit (by default, it can be increased and the spec supports it very easily).  However, Stratum also does support ntime rolling, the official spec is that ntime should not be increased faster than real-time.

Maybe I missed something, but from what I can see the Stratum spec only says you get an ntime from the server and you send one back. I can't find where it says how you should treat this value?

Just don't increase it faster then real time. But the real salient point is can you really preform 4.2 billion times the work of a single work unit in 30 seconds?
Yes I see that you could bite off sections to feed verious hashing contraptions and roll the time at the speed of real time to keep them spitting out results. Far more sensible would be to have a que built in to said hashing gizmo to actually allow pre loading the next work unit making the usb time a non issue.

[kano]

What ckolivas said. My point is that ntime doesn't need to be exact to the second. We could require every miner to own their own atomic clock, but why bother.
...

In any protocol, the time will be wrong while we hash at 5/10/20 seconds per nonce range, coz if you set the time when you start hashing, the time when you find a nonce will be later.
You can't even predict it coz with e.g. a 250Mh/s device, it can take 17s to complete the nonce range, but guess what, the first nonce returned will depend on the device.
If it's an Icarus, ModMiner or Cairnsmore1, then the time is unknown. you don't know when it will find a nonce.

But that is all to do with keeping the time close to the block find time.
Setting it during Stratum mining wont make much difference (up to 30s - or on average 15s)
Yes if you set it for Stratum or GBT it will be closer than not setting it (though GBT extends transaction confirm times by on average 1 minute instead of average 15 seconds like Stratum so in the GBT case you can multiply that 15s/30s by 4)

I've no idea where anyone has actually said that it would be a bad thing to set the ntime - it doesn't matter much in the Stratum case, though, coz the time it still small.

The problem is roll-n-time (on GetWork) which can create blocks up to 2 hours in the future when abused (or if used on soon to be seen high GH/s ASICs)
Luke's pool used to set them way in the future on occasion - e.g. 90 minutes - no idea if it was a long ongoing bug, crap programming or by his choice - but of course it's pointless asking coz you've no idea if what he replies is true or not.

[kano]

What ckolivas said. My point is that ntime doesn't need to be exact to the second. We could require every miner to own their own atomic clock, but why bother.

Stratum does not need ntime rolling because a single stratum work unit is 4.2 billion times larger than a standard getwork unit (by default, it can be increased and the spec supports it very easily).  However, Stratum also does support ntime rolling, the official spec is that ntime should not be increased faster than real-time.

Maybe I missed something, but from what I can see the Stratum spec only says you get an ntime from the server and you send one back. I can't find where it says how you should treat this value?

Just don't increase it faster then real time. But the real salient point is can you really preform 4.2 billion times the work of a single work unit in 30 seconds?
Yes I see that you could bite off sections to feed verious hashing contraptions and roll the time at the speed of real time to keep them spitting out results. Far more sensible would be to have a que built in to said hashing gizmo to actually allow pre loading the next work unit making the usb time a non issue.

Luke suggested bASIC is going to do that (which would be good) though hopefully the device will actually provide you with information regarding each work item sent so that there is no guessing about how much work has been done (same with a higher diff MCU)
Edit: and of course the ability to flush the queue and abort work

[Roy Badami]

You can still roll the time once per second, starting the second nonce field all over again. It really isn't going to be an issue unless some dramatic new technology that doesn't even exist yet is thought up and developed and manufactured and released in the decades ahead. Quantum computers anyone?

Why only once a second?  An ASIC is going to run through all nonces in far less than a second - why can't it roll ntime rapidly at least for a few seconds?  No one cares if ntime is exact to the second, as long as it's roughly right.

You still haven't understood? To go through all the nonces with stratum currently as is, would require it to check 18,446,744,073,709,551,616 hashes. If that's not enough, you can just increase the size of nonce2 from 4 to 6 and get 1,208,925,819,614,629,174,706,176 hashes. This is without rolling the ntime at all. If that's not enough, rolling the ntime just once every second will give you 1,208,925,819,614,629,174,706,176 hashes per second.

The argument (I think) is that you'd have to rebuild the merkleroot with each extranonce, which requires extra work to either be done on the CPU, or on-board future ASICs (would be recommended, due to latency of relaying new work between the miner and the ASIC), meanwhile with ntime rolling there is no extra building of work, just increasing a secondary counter in the header.

Right.

What I'm envisaging happening is that host will tell hardware to mine with a given block header and ntime range (from now to now+30 seconds, say).  a 60GH/s miner will take about 2 seconds to complete this work.

Then the host will increment extranonce and compute a new block header, and again tell the hardware to mine with the new block header and a new ntime range (again from now to now+30).

So one transaction every two seconds per 60GH/s miner.

The alternative, when driving hardware that doesn't support calculating Merkle roots, would be a minimum of 14 transactions per second per 60GH/s miner, maybe more depending on the design of the mining protocol.

Ok, you and Con have convinced me that host CPU isn't of itself going to be a problem. But does this architecture really scale?  What if your host is driving a couple of dozen 60GH/s miners?  Are you confident that the USB bus will take kindly to hundreds of transactions per second?  Are you confident that all host OSs you're targeting will service the USB interrupts in a timely enough manner when you're doing hundreds of transactions a second?

It may well be a non-issue.  But it just seems so easy to avoid potential problems here simply by allowing the hardware to work with an ntime range.

ETA: is there a risk of USB bus contention if asynchronous notifications are rapidly coming back from a large array of miners (e.g. to notify completion of work units)?

roy

[eleuthria]

Ok, you and Con have convinced me that host CPU isn't of itself going to be a problem. But does this architecture really scale?  What if your host is driving a couple of dozen 60GH/s miners?  Are you confident that the USB bus will take kindly to hundreds of transactions per second?  Are you confident that all host OSs you're targeting will service the USB interrupts in a timely enough manner when you're doing hundreds of transactions a second?

As for running a dozen 60 GH/s miners.  Assuming we ever get to that point where a single device is registered as 60 GH/s [something tells me those ASICs will be recognized as multiple smaller devices], and somebody has a farm like that with a single controller PC, the miner could use ntime to reduce overhead if needed.

Assign each device ntime+x, and send them the same work with a unique ntime [this is assuming the devices do not support internal ntime adjustment].

[Roy Badami]

Ok, you and Con have convinced me that host CPU isn't of itself going to be a problem. But does this architecture really scale?  What if your host is driving a couple of dozen 60GH/s miners?  Are you confident that the USB bus will take kindly to hundreds of transactions per second?  Are you confident that all host OSs you're targeting will service the USB interrupts in a timely enough manner when you're doing hundreds of transactions a second?

As for running a dozen 60 GH/s miners.  Assuming we ever get to that point where a single device is registered as 60 GH/s [something tells me those ASICs will be recognized as multiple smaller devices], and somebody has a farm like that with a single controller PC, the miner could use ntime to reduce overhead if needed.

Assign each device ntime+x, and send them the same work with a unique ntime [this is assuming the devices do not support internal ntime adjustment].

Not sure that helps a whole lot, except to reduce the number of Merkle roots the host has to compute (which we've already agreed is a non issue for the forseeable future).

With your proposal the host still needs to send work to each 60GHz miner 14 times a second to keep it busy.  (That's true no matter how it's structured as a cluster, I think.)

roy

[slush]

With your proposal the host still needs to send work to each 60GHz miner 14 times a second to keep it busy.  (That's true no matter how it's structured as a cluster, I think.)

I'm not sure about USB protocol used in first ASICs, but 14 packets per second is *absolutely* without any problem. It is at least 100x less than any possible limitation. I think you're trying to solve non-issue.

[antirack]

Line 115 in getwork_listener.py on the proxy:

print '!!!', self.stratum_port

Produces a lot of !!!! 3333 in my output.

Reason to be concerned, debugging left over or something else?

[slush]

print '!!!', self.stratum_port

Oh, sorry! Please update, I just fixed it.

[antirack]

No worries, I commented it out in the source and restarted the proxy already.