Topic: Handle much larger MH/s rigs : simply increase the nonce size - page 3. (Read 10064 times)

No, I'm talking about the current silicon without implementing a merkle processor + coinbase generator in silicon.
The work arounds.

Go ahead and tell everyone that the millions they are throwing at ASIC at the moment will be worthless soon

As I have already said, no company would be silly enough to do Stratum or the other thing in silicon since there is the issue of meeting the random requirements of the 'next' hack solution to this problem and thus no idea how long any device using this silicon could be used.
ROI ..........

I'm sure that when the alternative is Bitcoin becoming useless (either by scaling issues or broken cryptography), getting a consensus about the necessity for upgrade won't be a problem (most likely still very hard, but doable).

Good luck getting the Bitcoin community convinced that it's necessary because of a performance problem for miners, who are already making money.

GBT was necessary even before ASIC, because the real problem isn't the nonce range being too small, it's that pooled mining today tends to centralize control too much. The primary key feature of GBT is decentralization; that it happens to also solve the ASIC problem came as a nice side-effect.

Your sig says 54Gh/s, which would consume 12.5 merkle roots per second. You don't need to send the whole header, only the merkle root changes. That's 12.5 * 32 = 402 bytes per second.

It would be a little strange a device that can process 4 billion hashes faster than you can give it the 32 bytes to hash.

Edit:
Also it only needs a enough merkle roots to last for 1 second. After 1 second it can update nTime and cycle through its supply of merkle roots again. If you sent it the block header and 13 merkle roots, it would have all it needs.

Sure. My post was about that I prefer "work around" in miners that breaking compatibility of whole bitcoin network.


USB 2.0 has teoretical speed 480 Mbit/s. Block header has ~200 bytes. I know I'm over-simplifying it now, but teoretically it is possible to transfer up to 300000 block headers per second to the miner even with prehistoric USB 2.0.

Maybe we should focus to fixing protocols in these devices than fix protocol in bitcoin network? Why should device for $30k USD use serial port communication designed in the middle of 20th century?

I think you're missing something here. 0.7.0 was most certainly not forced on anyone. It does implement BIP34 (a fully backward-compatible change), which only takes effect as soon as a majority of mining power participates in it. Therefore it's indeed preferrable for miners and other infrastructure to upgrade to 0.7.0. But the key word in here is backward compatible. Every change that has ever been done, either had no protocol impact (like removing getmemorypool) or only a backward-compatible one (like BIP16 and BIP30).

What you are proposing is a completely incompatible upgrade. Blocks created by a new miner would simply be ignored by every single old node (not just old miners, everyone). The moment such a block gets created, and a majority of mining power is behind the change, there will instantly appear a fork in the block chain. One side maintained by the new nodes, one side by the old nodes. Every existing non-spent transaction output before the split would get to be spent once in each side. This would be a disaster. The only way such a "hard fork" as it is called (essentially a non-backward compatible change to the validity rules for blocks) is possible, is when it is very carefully planned in advance (let's say 1-2 years) and everyone agrees (not just a majority, there must be exceedingly high consensus about this).

I'm sorry, but no, a performance problem for miners is not worth a hard fork. Miners make money, I'm sure they'll find solutions on their own (like Stratum) which don't require the rest of the network to upgrade. If the hardware or the software can't deal with such high performance, switch to other hardware or software. Let the device do ntime rolling or calculate its own merkle root. Yes, I fully agree a 64-bit nonce would have made things easier, but there is simply no way of changing
that right now. I don't mean hard - it's just impossible. Some people would refuse to have a protocol change forced on them, and that's enough to ruin Bitcoin in the face of a hard fork.

Repeating and explaining ... since it seems to be necessary ...

If the time to talk to the device is of the same order of magnitude as how long the device takes to process the work, then there is a problem.

I deal with this stuff in e.g. the cgminer Icarus and BFL drivers.
The issue of how much time is wasted talking to the device.
It is already noticeable in the last digit of the miner performance display.
With a 10x performance increase (ASIC) it will be noticeable even more.

What x performance will we get from a device this year ... next year ... after that ... ?

Nothing to do with CPU speed.

His point is stealing 2 bytes from version shouldn't be a hard fork or any fork. (unless 0.7.0 panics when it sees a new version number, I haven't read that code yet...  nVersion is a signed int, so you could stipulate the high bit set so it makes a negative version number for <=0.7.0)

The version bytes were put there for extensibility. We need some now. We could use them now, or save them for some future need for bytes.

OTOH, Stratum seems to solve this nicely. The CPU has to do about 10 hashes and send 32 bytes of merkle root for every 4 billion hashes the ASIC does. ASIC is fast but is it anywhere near 400,000,000 times faster than CPU? I think CPU is like ~4 Mhash, so ASIC would have to be 100 petahash to outrun CPU's part of the job.

Although I thought it was obvious - I added the quote to my post above for the reason for my post above ...

However, slush, even your post directly implies working around the problem rather than fixing it.

... and it won't be long before each of the software workarounds will not be sufficient and then a workaround will be necessary in the silicon also.


... or ........ just fix the actual problem in the first place (yeah 3 months have already been wasted)

It is clearly a problem and there is a clear fix - a LONG term fix - increase the nonce size to 128 bits.

"Solves small iteration space without need of protocol hard fork." Isn't that reason big enough?


The restriction is that changing nonce size don't affect only miners, but all participants in bitcoin project. Breaking compatibility is always the last possible step, because it brings unnecessary instability.

Although I may agree that bigger nonce size would be the cleanest solution, it is simply not feasible in the real world. Looks like some people are too focused in mining, but protocol change is not just about mining. There already exists solutions which solves issues for miners, so I'll definitely prefer these solutions before breaking whole network.

So if nonce size isn't too small - why are we changing bitcoin at all to support ASIC?

Why is this stupid BIP in 0.7.0 that's been forced on everyone, that also removed functionality from bitcoind, necessary?
Why have people called sticking more junk in the coinbase an 'extra' nonce? What? They gave it the wrong name?
The current nonce is big enough? It's not necessary?

Why is Stratum necessary?
Coz when you get a block header to hash, you can only hash 2^32 times before needing to change it.
Why does that restriction exist?

What was the stupid (short term) hack used up until now? Roll ntime?
Why? Certainly couldn't be related to the nonce size?

It's gonna work fine without any changes right?

Oh ... no, that's not correct

Where IS the restriction at the moment?

OK back to the topic subject now

I would like to very explicitly disagree with this. I've never thought this and I joined the thread over a month ago I'd say. There is no reason to go through the trouble of a hard fork to implement a solution in search of a problem.

If this were put up for a vote by miners (similar to bip 16) where miners vote with their hashing power (though I do think this gives mining pool operators extra say since they're voting with their entire pool's hash rate), since they're the ones most affected and the ones who should care.

Sigh - it does become rather silly if you look at it from this perspective:

People are suggesting ways to solve the problem that the nonce size is too small (including Stratum and that other guff like that)

So ... what's the problem?

The nonce size is too small (as everyone agrees so far who has posted)

So ... make it bigger ... as I said in the first post 3 months ago ... though as I said later - 128 bits is a very long term solution.

... and as I said on the previous page ... create a version 2 block type that has the bigger nonce and set it to some time in the future
Yeah we've already lost 3 months ... though I guess in another 3, 6, or 9 months this wont be fixed and people will have the same excuse then that hard forks can't be done ...

It's ridiculous, completely unnecessary, and craps on one of our very few backwards compatible upgrade mechanisms. Backwards compatibility means we may need to put some data there in the future— since even incrementing the version can't change the layout without creating a hard fork. Perhaps worst of all, it's simply tasteless. The version field? really. yuck.

Even a fairly slow computer can do extra-nonce advancing for many TH/s, esp once considering a few bits of ntime rolling— well, at least if someone doesn't insist on writing their SHA256 in javascript or other ultra slow interpenetrated language... And all these TH/s are not free. If someone can't manage a modest CPU or two per hundred thousand dollars in mining asics then they have a financial management problem that no amount of protocol fiddling can fix. Certainly it's not healthy for the network to encourage miners which are so CPU starved they can't even afford to update their coinbases enough to keep up with their hardware even given the ~2^48 work reduction that they get from nonce plus ntime rolling.

As far as communications goes, presumably people engineering products that cost as much as a nice car are smart enough to not use lawnmower wheels on it when it needs tank treads. If they aren't then I feel bad for their customers for all the other bits of the design they'll get wrong. But since its totally unprecedented that some mining hardware maker would produce a horribly mismatched design which did something daft like provide their hardware with a fraction of the required power supply we should have nothing to worry about…

Yea, that's been my reaction on a lot of these proposals. To me a lot of this thread seems like "Holy crap, ASICs mean nonce won't be enough and bitcoin will break and my 56 billion bitcoins will be worthless because the network will break and my 23 TH/s rig won't be able to request work fast enough. And then ways to radically alter the syntax of the block to allow for more play room in each block (doubling the nonce range (which is one of the more sane requests), using two bytes of the version header as extra space for nonce, making things up to add in as extra hashes).

Don't get me wrong, especially for larger rigs (BFL's 1.5TH/s for one) trying to use difficulty 1 getworks from a pool server isn't realistic at all.

What I'd like to see is a small device (think the size and power of a phone or home router) that can manage a few miners (say around 10 TH/s of miners) over a local connection (which would help keep latency low among other things). On top of that I'd like to be picky and say that everything should be connected via ethernet, possibly even using power over ethernet (up to ~25W / 25GH with BFL's current specs). Just imagine if setting up new mining gear involved plugging in 1 ethernet cable per miner (plus a little config setup, or possibly them automatically syncing to the mining sever they're connected to).

Not the whole field, just take a couple of bytes from it. 2 bytes is more than enough for version information...

WTF I just read. Use block version as extra-extra-nonce?

Realistically, GBT (BIP 22/23) solved this for the pool/software end a long time ago, and stealing 8 bits from the ntime (about 3 minutes of rolling) is probably plenty for the hardware side for a while...

While using [part of] the block version as another nonce was at one time a possibility, starting with 0.7.0 any changes there will cause the client to report an upgrade required. And again, it's not necessary.

Block's nVersion policy is already specified, in the recently accepted BIP 34 - "Block v2, Height in Coinbase"

Please do not use nVersion as an additional nonce.

Stratum mining and getblocktemplate (BIP 22) already have provisions for ASIC miners, through the extraNonce field and other possibilities.  This provides unlimited nonce range.

Any change to the block header is a hard fork upgrade, and should be avoided at all costs.