Handle much larger MH/s rigs : simply increase the nonce size

[Gavin Andresen]

My current rig could count those 4 billions in 30 ms or less. That's less than usb handshake to xfer the new payload will take in average.

... so transfer 1,000 headers with different extranonces in one handshake.  Or don't handshake every time. Or modify the firmware that speaks whatever mining protocol you're sending at it to do the increment-extranonce-and-recompute-the-merkle-root-thing itself.

All of this discussion is useless; even if you could convince us core developers that we need A HARD FORK RIGHT THIS VERY MINUTE! there is absolutely zero chance we could make that happen before the ASICS start shipping.

So: plan accordingly.

[1715291226]

1715291226

[1715291226]

1715291226

[1715291226]

1715291226

[kjj]

Its not misdesign, its trade-off. The 32 bit nonce is old design, probably it looked great when only CPUs where doing mining, but right now it looks like a bottleneck.

It doesn't not look like a bottleneck. It provides a factor of four billion in reduction in whatever serial task exists outside of that. I have yet to see any evidence that it's a bottleneck.

My current rig could count those 4 billions in 30 ms or less. That's less than usb handshake to xfer the new payload will take in average.

You are getting 140+ Ghash/sec on a single device?  Today?  In reality?

[btharper]

Its not misdesign, its trade-off. The 32 bit nonce is old design, probably it looked great when only CPUs where doing mining, but right now it looks like a bottleneck.

It doesn't not look like a bottleneck. It provides a factor of four billion in reduction in whatever serial task exists outside of that. I have yet to see any evidence that it's a bottleneck.

My current rig could count those 4 billions in 30 ms or less. That's less than usb handshake to xfer the new payload will take in average.

You are getting 140+ Ghash/sec on a single device?  Today?  In reality?

+1

Most devices don't process one hash from 0 to 4 billion in (total hashrate/4 billion), they run several processes in parallel across several chips. So each of your 20 onboard chips are each (relatively) slowly chewing through work and needs a new piece of work every several hundred milliseconds.

Also as Gavin said, send more than one piece of work for each handshake. Between longpoll and everything else that's setup, I don't see any reason not to have several pieces of work queued up and ready to go on the device side of the USB cord.

[beekeeper]

My current rig could count those 4 billions in 30 ms or less. That's less than usb handshake to xfer the new payload will take in average.

... so transfer 1,000 headers with different extranonces in one handshake.  Or don't handshake every time. Or modify the firmware that speaks whatever mining protocol you're sending at it to do the increment-extranonce-and-recompute-the-merkle-root-thing itself.

All of this discussion is useless; even if you could convince us core developers that we need A HARD FORK RIGHT THIS VERY MINUTE! there is absolutely zero chance we could make that happen before the ASICS start shipping.

So: plan accordingly.

Bulk transactions are for video streaming. Anything derived from financial transactions should have every byte handshaked.
Ofc, it can be done like that, but again, we are back at start, I have to overdesign chip controllers to cover extra bandwidth.
BTW: I never intended to start arguing, its rather, as I said, an annoyance I wanted to talk about.

[slush]

Ofc, it can be done like that, but again, we are back at start, I have to overdesign chip controllers to cover extra bandwidth.

It is nice to see you agree that the only problem is sub-optimal software in miners.

a) Optimize wrongly designed mining software
or
b) Hard fork of whole bitcoin network?

I vote for b)

Btw it would be quite comfortable for me to agree with you. With bigger nonce range I won't need to switch to Stratum protocol, because getwork protocol would be good enough for ages. But still I decided that there's much easier solution than trying to do hard fork, so I just re-designed protocol. Btw it isn't easy, I'm working on it almost two months on full time.

Stop calling optimizations "work arounds" and let's go back to work.

[kano]

My current rig could count those 4 billions in 30 ms or less. That's less than usb handshake to xfer the new payload will take in average.

... so transfer 1,000 headers with different extranonces in one handshake.  Or don't handshake every time. Or modify the firmware that speaks whatever mining protocol you're sending at it to do the increment-extranonce-and-recompute-the-merkle-root-thing itself.

All of this discussion is useless; even if you could convince us core developers that we need A HARD FORK RIGHT THIS VERY MINUTE! there is absolutely zero chance we could make that happen before the ASICS start shipping.

So: plan accordingly.

Yes - plan ... that's the point of this thread ... but not of the "We can't ever do a hard fork" devs
... and that your post clearly shows a lack of understanding 'planning'.

Plan for a future hard fork to allow a 2nd version block header.
The issue is obvious, the cause is obvious, the path to ultimately fix it is obvious, but then you make this stupid statement
"A HARD FORK RIGHT THIS VERY MINUTE"
... who said that? (other than you)

Though - as has already been pointed out - this issue came up 2 years ago ... yeah a lot of foresight back then ignoring it
No doubt nothing was learned from that mistake.

[tacotime]

So... has this issue been resolved?  Will it still break all ASICs if they get too fast?

[TierNolan]

So... has this issue been resolved?  Will it still break all ASICs if they get too fast?

You can send much more complex info to miners now.  The "getblocktemplate" rpc call allows the pool to give miners enough info to generate their own headers on the fly.

[btharper]

So... has this issue been resolved?  Will it still break all ASICs if they get too fast?

You can send much more complex info to miners now.  The "getblocktemplate" rpc call allows the pool to give miners enough info to generate their own headers on the fly.

Seconded. Between Stratum and GBT there really wasn't a problem and one failed to materialize for no reason. Everything's moving along nicely now. Probably an idea worth revisiting in the future if there's another, more important, reason to do a hard-fork (like switching to SHA-512 or an SHA-3 family item) which would break current ASICs due to the massive change in protocol.

[kano]

So... has this issue been resolved?  Will it still break all ASICs if they get too fast?

You can send much more complex info to miners now.  The "getblocktemplate" rpc call allows the pool to give miners enough info to generate their own headers on the fly.

Seconded. Between Stratum and GBT there really wasn't a problem and one failed to materialize for no reason. Everything's moving along nicely now. Probably an idea worth revisiting in the future if there's another, more important, reason to do a hard-fork (like switching to SHA-512 or an SHA-3 family item) which would break current ASICs due to the massive change in protocol.

Stratum, GBT and "getblocktemplate" have not solved this in any way whatsoever.

As before, each single nonce work item that allows for O(9) tests, is sent to the device.

At the moment, still no miners do any more than this.

The solution I presented a year ago would allow the information sent to the device to be able to produce O(9) more results with just a 32 bit extension to the nonce size - i.e be future proof by simply increasing it by O(9) (32 bits) O(19) (64 bits) or even O(28) (48bits) easily enough

The solution you are implying (that doesn't exist) would be to code the stratum protocol into the mining device, rather than having the extreme simplicity of just having a counter that is larger.

GBT is not even relevant to the topic since having to send up to a megabyte of data to the mining device at least every 30s and delaying work restart after an LP until that data is sent is ridiculous.