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

[kano]

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.

[1714103215]

1714103215

[1714103215]

1714103215

[1714103215]

1714103215

[1714103215]

1714103215

[1714103215]

1714103215

[1714103215]

1714103215

[jevon]

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

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.

[kano]

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.

[Pieter Wuille]

Why is this stupid BIP in 0.7.0 that's been forced on everyone, that also removed functionality from bitcoind, necessary?

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.

[slush]

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

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

I deal with this stuff in e.g. the cgminer Icarus and BFL drivers.

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?

[jevon]

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.

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.

[kano]

Why is this stupid BIP in 0.7.0 that's been forced on everyone, that also removed functionality from bitcoind, necessary?

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.

So you've plotted out the timeline for the death of BTC yet?

Either of these will do:
1) When the number of transactions on the network is beyond what the current design can support
2) When sha2 IS broken (not an IF, a WHEN) and we have to move on to sha3

According to your argument, when either of these happen, BTC will die since a hard fork isn't possible.

Yes I know the soft fork in April was done badly, but just because it was fucked up then, doesn't mean soft or hard forks can't be done.

[Luke-Jr]

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.

[Pieter Wuille]

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.

[kano]

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.

Your sig says 54Gh/s, which would consume 12.5 merkle roots per second. 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.

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

[kano]

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.

A perceived problem that even MOST of the network disagrees with you on.

MOST of the network mines on pools - count the % of network using P2Pool or solomining and you will see your argument that GBT solves some control problem holds no water at all.

[jevon]

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.

Your sig says 54Gh/s, which would consume 12.5 merkle roots per second. 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.

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

So was I.

I'm sorry, maybe I'm missing something. The CPU increments the coinbase extra nonce and recalculates the merkle branch to make new merkle roots to send to the ASIC. Only the merkle roots need to go over the wire.

[Luke-Jr]

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.

A perceived problem that even MOST of the network disagrees with you on.

MOST of the network mines on pools - count the % of network using P2Pool or solomining and you will see your argument that GBT solves some control problem holds no water at all.

p2pool and solo, while they do require decentralization, are not unique in supporting it, and both come with their own problems.

[slush]

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.

+1

As I have already said, no company would be silly enough to do Stratum or the other thing in silicon

Stop spreading FUD. Nobody is talking about implementing Stratum/GBT directly in chip.

How about that huge possible optimizations on wire protocol between computer and device? Why not to optimize this at first time? You told that current wire protocols has problems with handling few block headers per second. If that's true, then you can get many orders of magnitude in performance just by optimizing it, without breaking anything in bitcoin.

Oh, I forgot, it is because you need drama :-P.

[gmaxwell]

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

We are not and have not.

Why is this stupid BIP in 0.7.0 that's been forced on everyone, that also removed functionality from bitcoind, necessary?

Wtf are you talking about.

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?

Extranonce has been part of the design since day one. It was the only way to make your coinbase transactions have unique IDs other than constantly changing to a new public key whenever you update the candidate block. It's fundamental and is required for things independent of the nonce size.

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?

A _4 billion to 1_ work factor is pretty reasonable. There are a couple tradeoffs here. Header size is utterly critical for SPV nodes of various kinds, and even adding a single byte to the header increases the size by 1.25%. Having too much workfactor ratio between header only work and block update work encourages miners to build devices which never process transactions: Cheaper to just build a constant root with no transactions and increment the header until you solve a block. On a fresh design I may have given a bit more space to nonce, sure. But there is no need to change it now.

It's gonna work fine without any changes right?
Oh ... no, that's not correct

Yes, in fact it will.

Yes I know the soft fork in April was done badly, but just because it was fucked up then, doesn't mean soft or hard forks can't be done.

Huh? The P2SH deployment went pretty smoothly.  About the only bad thing that came out of it was that we discovered Bitcoin had a bug in handling large reorgs with lots of transactions.  Timed less well— with large miners unable to reorg because of it— this could have been pretty fatal for the network. But since it only really impacted non-mining nodes (plus the tiny minority of non-updated miners) due to fork being invalid P2SH it was harmless. It's very fortunate, because I'm not sure we would have discovered that BDB issue even by now wthout it.

Where IS the restriction at the moment?

That we're not permitted to throw you into a volcano.

[kano]

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.

+1

-2, keep reading

As I have already said, no company would be silly enough to do Stratum or the other thing in silicon

Stop spreading FUD. Nobody is talking about implementing Stratum/GBT directly in chip.

How about that huge possible optimizations on wire protocol between computer and device? Why not to optimize this at first time? You told that current wire protocols has problems with handling few block headers per second. If that's true, then you can get many orders of magnitude in performance just by optimizing it, without breaking anything in bitcoin.

Oh, I forgot, it is because you need drama :-P.

At least make sure you know what you are talking about before hitting reply

Firstly - show me where I said "few block headers per second" - at least quote correctly ...

If you are dealing with work at a nonce range level, then for each nonce range you are passing work to the device.
If the transfer of the ~60-80bytes of hash data to the device is even within an order of magnitude of the device in processing that data, then you have a problem.

FPGA's that use serial over USB have the beginnings of this issue - as per: BFL, Icarus, ModMiner, Cainsmore.
... and the 2 companies that will be releasing their ASIC first are 2 of those, BFL and ModMiner, with Icarus not far behind.

The work arounds suggested imply implementing merlke root processing and coinbase generation processing in silicon ... as I have already explained ... but since it was a little difficult for you to understand I've repeated it. Maybe you are at the top of the first curve

Anyway, yet again, a work around to resolve the problem that the nonce size is too small.
However, how generic is that work around if it was implemented in silicon?
Would it 'always' work or would it only work with current implementations and need changing in the not too distant future?
Quote me: "ROI"

All these problems and questions are actually resolved by simply increasing the size of the nonce field.
The cause of the problem, and the correct and simplest solution to the problem.
The only argument against it is a hard-fork - which can be planned as a future change to resolve the problem before it becomes a problem.
Yeah a little forward thinking goes a long way.

All this melodrama about hard-forks being impossible - well when the first one comes along that is required 'now', then clearly that will be the end of BTC since everyone's argument is that it is impossible do a hard-fork ... ... which in this case is to fix the problem at the root cause - that then solves all related issues with one change - and a simple implementation everywhere.

As I'll repeat as I've implied before, this really is a good example of people failing to learn from the past.
In this case, a well know one, MSDOS and the early x86 architecture, where the design was based on an assumption that turned out to be an obvious underestimate not far down the track, and for years hacks were used to work around the problem because it was considered too difficult to fix it properly ... until it was fixed properly by removing the original constraints.

[kano]

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

We are not and have not.

Oh that's right, GBT related changes didn't happen in bitcoind - I forgot.

Why is this stupid BIP in 0.7.0 that's been forced on everyone, that also removed functionality from bitcoind, necessary?

Wtf are you talking about.

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

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?

Extranonce has been part of the design since day one. It is the only way to make your coinbase transactions have unique IDs other than constantly changing to a new public key whenever you update the candidate block. It's fundamental and is required for things independent of the nonce size.

Ah glad you agree, yes the nonce field is too small, the solutions using Stratum and GBT have had to extend it to the coinbase
So ... where is extra nonce referred to in the original Bitcoin document by Satoshi? Oh it isn't.
I'd guess you like the Roll ntime hack also?

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?

A _4 billion to 1_ work factor is pretty reasonable. There are a couple tradeoffs here. Header size is utterly critical for SPV nodes of various kinds, and even adding a single byte to the header increases the size by 1.25%. Having too much workfactor ratio between header only work and block update work encourages miners to build devices which never process transactions: Cheaper to just build a constant root with no transactions and increment the header until you solve a block. On a fresh design I may have given a bit more space to nonce, sure. But there is no need to change it now.

"you may have"
Read previous post

It's gonna work fine without any changes right?
Oh ... no, that's not correct

Yes, in fact it will

Ah, OK, none of these Stratum or GBT changes were needed. OK.
Since they are hacks anyway, just throw them away then.

Where IS the restriction at the moment?

That we're not permitted to throw you in a volcano.

But you are permitted to run back to Luke's lap ... wan wan

[Luke-Jr]

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.

[slush]

How about that huge possible optimizations on wire protocol between computer and device? Why not to optimize this at first time? You told that current wire protocols has problems with handling few block headers per second. If that's true, then you can get many orders of magnitude in performance just by optimizing it, without breaking anything in bitcoin.

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?

Once again, bolded especially for kano. Please respond to this.

If you are dealing with work at a nonce range level, then for each nonce range you are passing work to the device.

How many iterations is possible for one nonce range? 2^32? So 80 bytes per 2^32 hashes? Is that around 230 low-level "jobs" (nonce ranges) per one terahash per second? Isn't there teoretical wire limit 300000 nonce ranges per second for USB 2.0?

FPGA's that use serial over USB have the beginnings of this issue - as per: BFL, Icarus, ModMiner, Cainsmore.
... and the 2 companies that will be releasing their ASIC first are 2 of those, BFL and ModMiner, with Icarus not far behind.

Serial over USB is that obsolete technology which I was refering in my previous post. Looks like *there* is a space for improvements, *not* in bitcoin protocol.

The work arounds suggested imply implementing merlke root processing and coinbase generation processing in silicon ...

Nobody is proposing this.

Would it 'always' work or would it only work with current implementations and need changing in the not too distant future?

Yes. There're already technologies for feeding Petahashes per second to ASIC device. However device manufacturers will probably need to drop obsolete wire protocols and use something faster than Serial over USB.

All these problems and questions are actually resolved by simply increasing the size of the nonce field.
The cause of the problem, and the correct and simplesthardest solution to the problem.

Let me fix it for you.

The only argument against it is a hard-fork

It looks to me that you live in some alternate universe. Hard fork is definitely possible and there can be scenarios when it become necessary, but ASIC miners are not that case.

*headdesk*

[gmaxwell]

Oh that's right, GBT related changes didn't happen in bitcoind - I forgot.

HUH? GBT is a rename of the poorly named getmemorypool which we've had for a long time— much longer than anyone was talking about 1TH/s mining devices— it's used by pool daemons and p2pool. Mostly for dynamic coinbase creation (e.g. to do fancy payouts) and because bitcoind coinbase creation is somewhat slow (it's synchronous, single threaded, and basically completely unoptimized).  The changes made in 0.7 beyond the rename were some extra fields to remove a potential DOS attack where some of the limits couldn't be properly enforced when the caller does dynamic transaction selection, support for the height in the coinbase, and some general cleanups to make it more 'designed' than accreted. BIP 22 makes no mention of 'asic', nor do the pull requests for the changes, and I don't believe asics _ever_ came up in discussion related to it around the reference client's development.

To the extent that GBT is useful for higher speed miners getmemorypool was absolutely as useful.

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.

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.