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

[DoomDumas]

Voting for fixing root cause instead of patching problems...
IMHO, Kano argue about something interesting, about seeing much much farter in the future than we are used to.. all must learn from history..

meanwhile, I doubt ASICs or "miner will" are a reason to rush things..
Must be well planned, if concidered needed..  As I like to say :

What do we want ?
Evidence based change !
When do we want it ?
After peer review !

was my 2 satoshi !

[kano]

...

So ... where is extra nonce referred to in the original Bitcoin document by Satoshi? Oh it isn't.

The same place scripts are referenced as well as locktime and nbits.

Quote it - coz it isn't there.
Have even ever read "Bitcoin: A Peer-to-Peer Electronic Cash System"?

There were that many BIPs added in 0.7.0 that you couldn't work out which one I was referring to?

It's awfully hard to work out what you're talking about when you haven't the foggiest clue about what you're talking about yourself.

Yes I guess for someone like you it is difficult to only associate BIP 22 with the thread title.

I'm not sure how you could associate the thread title with BIP 34 or 35, but that confusion is (in your opinion) 'having a clue'
So I guess there's no point discussing this any further with someone as 'clued' in as you are

[Pieter Wuille]

BIP 22 doesn't have anything at all to do with the block validity rules, which is the one thing this is all about. It's about a client-specific way of making mining software interact with the daemon (but it can, and hopefully will, be adopted by other software too). You could replace the BIP22 implementation in the daemon you're using with any equivalent, and nothing would break - nobody would even notice - as long as you patch the software that interacts with it as well.

BIP 34 however does concern block validity rules. It's not directly related to mining, so maybe it is harder to see why it is relevant in this discussion.

[kano]

Kano, you're confused because you're only in Bitcoin for "free money". Someday, you'll need to realize "free money" is not really a goal for Bitcoin as a whole.

... lulz reality please.
Your desire to control bitcoin and your self-righteous intolerance have long ago blinded you to the FUD you regularly spread.

[btharper]

...

So ... where is extra nonce referred to in the original Bitcoin document by Satoshi? Oh it isn't.

The same place scripts are referenced as well as locktime and nbits.

Quote it - coz it isn't there.
Have even ever read "Bitcoin: A Peer-to-Peer Electronic Cash System"?

From wiki
I don't know the code well enough to reference it, but here's a reference by Theymos on the wiki from December 2010, which at the very least predates anything fast on the network. Per http://bitcoin.sipa.be/ the network back then was under 100GH/s.

So yes, people have been worrying about 2^32 not being enough for a long time, however if you're able to spin the merkle root yourself it's not a problem. Or if you're able to get a new one with relatively low latency (ie. Not from a remote web server, ie. pool) every time, it's okay and you can hash away on it.

Nothing about spinning new merkle roots has to be in silicon, a small microprocessor (CPUs on my ASICs?!?!?) would work fine, and probably exists there for other reasons, although it may not have enough power to do anything useful like generate new merkle roots.

[Pieter Wuille]

Generating a merkle root is exactly the same operation as the ASIC is specifically designed for already (double SHA256). No need to embed a CPU on the ASIC (an ASIC is a CPU, but one for a very specific purpose only).

That doesn't mean they should - it can be done at any stage (in the pool, in the computer controlling the asic, in some intermediate controller chip, ... I don't care). The point is that this is not hard; it's only different from how the current infrastructure works.

[2112]

I have nothing to add, I'm just quoting this gem for the future reference.

Generating a merkle root is exactly the same operation as the ASIC is specifically designed for already (double SHA256). No need to embed a CPU on the ASIC (an ASIC is a CPU, but one for a very specific purpose only).

That doesn't mean they should - it can be done at any stage (in the pool, in the computer controlling the asic, in some intermediate controller chip, ... I don't care). The point is that this is not hard; it's only different from how the current infrastructure works.

[btharper]

Generating a merkle root is exactly the same operation as the ASIC is specifically designed for already (double SHA256). No need to embed a CPU on the ASIC (an ASIC is a CPU, but one for a very specific purpose only).

That doesn't mean they should - it can be done at any stage (in the pool, in the computer controlling the asic, in some intermediate controller chip, ... I don't care). The point is that this is not hard; it's only different from how the current infrastructure works.

While the merkle root does use double SHA256, the optimizations are different. Where dsha(h) = SHA256(SHA256(h)), the merkle root is dsha(dsha(A+B) + dsha(C+C)) (for three transactions, one of which is the generation transaction). And the block hash is a highly optimized (for fewer operations which leads to quicker completion and higher speeds) down to precomputing the first round of SHA256, and running through one of two rounds of the inner iteration of SHA256 (the other being precomputed in the previous step) and the first 94% of the second iteration (the last 4 rounds don't matter).

TL;DR on that - merkle roots are a normal hash, insert data get answer. Block hashing wants a hash with a certain property and tries over an over with slightly different starting conditions to get a "special" end result. One cares about getting an answer for a specific input, one wants a specific output from a generic form of the input.

Also, because of several factors, it's a lot harder to make the merkle root generation in silicon (I'm sure it can be done, there's just not as much point, you can make them much more easily than hashing them. A few hundred hashes versus a few billion).

Also, an ASIC is by defenition Application specific. While you could make one to generate merkle roots via serial input, it'd be a lot of work for not a lot of gain. A CPU just does whatever you tell it to do. Generally on an embedded device like a mining rig a firmware update (more generally, a change in software) could completely change what the CPU is doing (for instance change how the merkle root is generated based on a new BIP), but the ASIC is stuck doing the exact same thing that it's orignally hardwired to do until it breaks.

Again to suggest a mining rig with fairly simple setup of plugging into ethernet and power cords (and configuring to a pool) could use a microprocessor to do all the work (talking to the network, deciding what transactions to include) EXCEPT crunching blocks which would be left to the ASIC part of the chip.

[gmaxwell]

So ... where is extra nonce referred to in the original Bitcoin document by Satoshi? Oh it isn't.

The same place scripts are referenced as well as locktime and nbits.

Quote it - coz it isn't there.
Have even ever read "Bitcoin: A Peer-to-Peer Electronic Cash System"?

I embedded the quote steganographically in the wooshing sound you heard as you read my response.

… The paper was written something like a year before the publication of the system. It covers the core concepts but omits things such as the script system, which is easily the most complicated part of a full node implementation. Since the paper covers _very_ little of the actual implementation, including a number of critical design decisions (I provided some examples of uncovered things), it would have been surprising if it _had_ mentioned extranonce.

Yes I guess for someone like you it is difficult to only associate BIP 22 with the thread title.
I'm not sure how you could associate the thread title with BIP 34 or 35, but that confusion is (in your opinion) 'having a clue'

Because:
(1) None of them were about ASIC mining. So I had to assume you were confused, and given that you are confused all bets are off.
(2) BIP 22 is primarily documenting (and cleaning up) an API we've had since long before 0.7; we merged it from forrestv in Septemberish 2011. So your talk about new in 0.7 more or less precluded it.

[beekeeper]

kano is right. I did encounter this bandwidth issue, its somehow the same annoyance for hardware developers as it was diff1 and multi GHs miners network bandwidth consumption for pool operators. Unfortunately, solving hardware bandwidth issues is not as simple as a workaround in software, most of the time it requires changing design and adding extra costs.

[gmaxwell]

kano is right. I did encounter this bandwidth issue, its somehow the same annoyance for hardware developers as it was diff1 and multi GHs miners network bandwidth consumption for pool operators. Unfortunately, solving hardware bandwidth issues is not as simple as a workaround in software, most of the time it requires changing design and adding extra costs.

Then don't mis-design your hardware in the first place. Seriously, if you can't do the small bit of multiplication to figure out what your bandwidth requirements will be then you _have no business making mining hardware_, operating pools, etc... Nothing suggested avoids changing design and adding costs. At best the suggestions externalize cost on future bitcoin users.

[kano]

Firstly regarding the change.

The current hash is actually 3 passes though the 64 stage hash function (2 x sha256 but the 1st sha256 is 80 bytes so requires 2 x 64 stages)
The first pass is unaffected by rolling the nonce value or any added data after it up to a certain size (and also would be unaffected by rolling the time value ... there you go hardware people - implement the Roll-NTime hack in there with a difficulty input also - but that would be risky ... and is short term)

Anyway, the size increase change would be to have a version 2 (or 3 or whatever is next at the time) block with the nonce field having 12 extra bytes (96 bits) added after the current nonce (which is currently on the end of the 80 bytes) making the block header 92 bytes.

The rolling would one of:
1) anywhere the hardware likes in the 128 bits that suited the hardware design best
OR
2) a subset given by a pool to allow the pool to avoid having to do any other major work than generate new merkle trees every time the transaction list needs updating (all the time )
I'd also add that the pool should be setting work difficulty high enough to appropriately (ask organofcorti) minimise work returned and work lifetime small enough to reduce transaction delays

What this change would mean is that ANY device designed with this option could be given work (and difficulty setting) and 'could' be given a time frame and then the device could hash up to the time frame and then stop, independent of the performance of the device (of course as some of the hardware vendors know, returning valid nonce's during hashing is the best way to give answers back)

Thus we also wouldn't have the other problem that the hacks cause:
Extra delays in Bitcoin transaction processing
since the time frames could be set to an appropriate value to minimise this effect (seconds) and ALL devices could guarantee that they could work for that (short) time frame and the mining software could spend that time processing results and setting up the next work ... as they all should (already )

---

Meanwhile, it is interesting to see people shift the problem around
e.g. slush saying it is the mining hardware problem - the hardware should have a faster 'wire' to deal with the problem - but it could rightfully be argued that it is also the pools problem - they should have faster hardware and better networks as required ... both are valid

This solution solves both

I will also give a very good example of how such arguments about the hardware ignore obvious limitations:
Xiangfu (as anyone with an Icarus should know who he is) had 91 USB Icarus devices connected to a single computer and a single cgminer instance running (with plenty of CPU to spare ) ... so with such a setup, you have to consider 2 orders of magnitude in performance ...............

My solution is a long term solution that (of course) is not going to happen today, but it seems the dev fear of hard forks any time in the distant future (and the fact mentioned by someone else that this nonce issue was brought up 2 years ago) probably means it will never be fixed.

No idea if there is much else to say, but I guess if the discussion has no more merit (due to this last point) then this is a far as it will go.

---

Aside: there is a well known bug in the bitcoin difficulty calculation that gets it wrong (always) but since it's wrong by a small % and that it requires a hard fork, it has never been fixed. Yes, how much you get paid for your BTC mining work, is actually always a faction low

I make this comment so as to shed more light on other comments about hard forks

[slush]

Slush is saying that it is mining *software* problem. Even with future ASIC miners it will be feasible to prepare block headers on decent computer. If there is any real problem, then it is just using obsolete protocols between computer and mining device.

[btharper]

Firstly regarding the change.

The current hash is actually 3 passes though the 64 stage hash function (2 x sha256 but the 1st sha256 is 80 bytes so requires 2 x 64 stages)
The first pass is unaffected by rolling the nonce value or any added data after it up to a certain size (and also would be unaffected by rolling the time value ... there you go hardware people - implement the Roll-NTime hack in there with a difficulty input also - but that would be risky ... and is short term)

Anyway, the size increase change would be to have a version 2 (or 3 or whatever is next at the time) block with the nonce field having 12 extra bytes (96 bits) added after the current nonce (which is currently on the end of the 80 bytes) making the block header 92 bytes.

The rolling would one of:
1) anywhere the hardware likes in the 128 bits that suited the hardware design best
OR
2) a subset given by a pool to allow the pool to avoid having to do any other major work than generate new merkle trees every time the transaction list needs updating (all the time )
I'd also add that the pool should be setting work difficulty high enough to appropriately (ask organofcorti) minimise work returned and work lifetime small enough to reduce transaction delays

What this change would mean is that ANY device designed with this option could be given work (and difficulty setting) and 'could' be given a time frame and then the device could hash up to the time frame and then stop, independent of the performance of the device (of course as some of the hardware vendors know, returning valid nonce's during hashing is the best way to give answers back)

Thus we also wouldn't have the other problem that the hacks cause:
Extra delays in Bitcoin transaction processing
since the time frames could be set to an appropriate value to minimise this effect (seconds) and ALL devices could guarantee that they could work for that (short) time frame and the mining software could spend that time processing results and setting up the next work ... as they all should (already )

---

Meanwhile, it is interesting to see people shift the problem around
e.g. slush saying it is the mining hardware problem - the hardware should have a faster 'wire' to deal with the problem - but it could rightfully be argued that it is also the pools problem - they should have faster hardware and better networks as required ... both are valid

This solution solves both

I will also give a very good example of how such arguments about the hardware ignore obvious limitations:
Xiangfu (as anyone with an Icarus should know who he is) had 91 USB Icarus devices connected to a single computer and a single cgminer instance running (with plenty of CPU to spare ) ... so with such a setup, you have to consider 2 orders of magnitude in performance ...............

My solution is a long term solution that (of course) is not going to happen today, but it seems the dev fear of hard forks any time in the distant future (and the fact mentioned by someone else that this nonce issue was brought up 2 years ago) probably means it will never be fixed.

No idea if there is much else to say, but I guess if the discussion has no more merit (due to this last point) then this is a far as it will go.

---

Aside: there is a well known bug in the bitcoin difficulty calculation that gets it wrong (always) but since it's wrong by a small % and that it requires a hard fork, it has never been fixed. Yes, how much you get paid for your BTC mining work, is actually always a faction low

I make this comment so as to shed more light on other comments about hard forks

The example you give is probably the biggest reason this won't be put in there anytime soon. While allocating even another 300 or so bits (to keep things in three total rounds of SHA256) would be just fine by me, the difficulty involved in making such a change in very basic levels of the protocol. If we ever have to move away from SHA256 I think that would be a good time to do this, but right now the biggest problem is latency between pool servers and the other side of the USB cord. Getting things across the USB cord is becoming a problem and will need to be addressed by hardware manufactures. A few implementation details (GBT from getwork) will change, and things will keep on keeping on. Yea there's a bit of optimism in that, but I don't feel it's unwarranted.

[kano]

...
The example you give is probably the biggest reason this won't be put in there anytime soon. While allocating even another 300 or so bits (to keep things in three total rounds of SHA256) would be just fine by me, the difficulty involved in making such a change in very basic levels of the protocol. If we ever have to move away from SHA256 I think that would be a good time to do this, but right now the biggest problem is latency between pool servers and the other side of the USB cord. Getting things across the USB cord is becoming a problem and will need to be addressed by hardware manufactures. A few implementation details (GBT from getwork) will change, and things will keep on keeping on. Yea there's a bit of optimism in that, but I don't feel it's unwarranted.

Nope.

It's placing data in 96 bits of zeros ... as I said ... and it is still inside the 3rd round that already exists.
That's not a new round I'm adding - it's already there.
3 rounds is not a change, I'm simply pointing out what a lot of people don't even realise is there already.
... and ... that most of the data added in the 2nd round is 'zero'

If I am correct in understanding Inaba's comments about the BFL ASIC, they may even support this possibility already.
(i.e. if they do a proper full 64 round hash each time and the silicon doesn't decide how that is processed - rather the replaceable firmware)

---

Also, as I said, you already need to consider 2 orders of magnitude in dealing with the hardware ... before ASIC turns up.
ASIC is less than 2 months away and that's just version 1 of anyone's ASIC hardware.
... which is another order of magnitude at the absolute least.

Considering a forward planning change set to arrive in 2 years (or even one year) - who knows what the hashing performance will be by then.

Consider an old ATI 6950 graphics card - it has the equivalent of 1408 complex cores in it (integer shaders)
If version 1 of the ASIC has the equivalent of say only 100 and the complexity is well below that of an ATI core, then performance gains could easily be 128x in just the next generation of ASIC ... yeah I chose that 128 number on purpose

---

Unless you have something new to bring to the discussion, I think this one has ended.

[btharper]

Nope.

It's placing data in 96 bits of zeros ... as I said ... and it is still inside the 3rd round that already exists.
That's not a new round I'm adding - it's already there.
3 rounds is not a change, I'm simply pointing out what a lot of people don't even realise is there already.
... and ... that most of the data added in the 2nd round is 'zero'

If I am correct in understanding Inaba's comments about the BFL ASIC, they may even support this possibility already.
(i.e. if they do a proper full 64 round hash each time and the silicon doesn't decide how that is processed - rather the replaceable firmware)

---

Also, as I said, you already need to consider 2 orders of magnitude in dealing with the hardware ... before ASIC turns up.
ASIC is less than 2 months away and that's just version 1 of anyone's ASIC hardware.
... which is another order of magnitude at the absolute least.

Considering a forward planning change set to arrive in 2 years (or even one year) - who knows what the hashing performance will be by then.

Consider an old ATI 6950 graphics card - it has the equivalent of 1408 complex cores in it (integer shaders)
If version 1 of the ASIC has the equivalent of say only 100 and the complexity is well below that of an ATI core, then performance gains could easily be 128x in just the next generation of ASIC ... yeah I chose that 128 number on purpose

---

Unless you have something new to bring to the discussion, I think this one has ended.

What I was saying is that you could add just over 300 bits of to the current data structure without messing with the three total rounds performed (the same three we have now).

Right now the move to bigger and better is cost prohibitive. While BFL and competitors can crank out massive machines doing in excess of a TH/s, getting MORE will cost more. Unless a giant like AMD gets into things, it won't be as cheap as a $200 graphics card.

Also in two years we'll be halfway through the 25 BTC blocks. At a quarter of the current reward (in 4 years) mining will be much less profitable (assuming BTC value doesn't shoot up, and I don't think expecting it to double each time the reward halves is reasonable).

Things are getting faster. Much faster. So what? It just sounds like panic to me. I do think we've reached the limits of what we can argue about though. If nothing else we're not getting anywhere.

Any chance we can get more details on the flexibility of the new ASICS?

[kano]

Depends on the NDA when I get one of the first ones

[beekeeper]

kano is right. I did encounter this bandwidth issue, its somehow the same annoyance for hardware developers as it was diff1 and multi GHs miners network bandwidth consumption for pool operators. Unfortunately, solving hardware bandwidth issues is not as simple as a workaround in software, most of the time it requires changing design and adding extra costs.

Then don't mis-design your hardware in the first place. Seriously, if you can't do the small bit of multiplication to figure out what your bandwidth requirements will be then you _have no business making mining hardware_, operating pools, etc... Nothing suggested avoids changing design and adding costs. At best the suggestions externalize cost on future bitcoin users.

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.

[gmaxwell]

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.

[beekeeper]

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.