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

No it means that this hardware is being design by short-sighted people that should not be designing hardware.

The US government mandated that SHA-1 no longer be used within the government after 2010.
Why? Because it was broken.
Is this something that people expect to never happen to SHA-2?
Why is there an SHA-3?
Seriously your argument is nonsense since, who knows, tomorrow SHA-2 could be broken.

Actually, it's a problem for pools not miners.
If a pool can't handle larger devices, when large MH/s FPGA or ASIC devices show up - ok we'll have pools failing around us.

It's not the issue of handling a few more higher power devices, it's the simple fact that if people can get these devices, then either everyone will be getting devices that are close to an order of magnitude faster, or most of the backbone of BTC (the miners) will be gone and BTC will die.
Anyone can see there is no exaggeration in that if they have a little sense of understanding of today's BTC network.

Yes there are other suggestion, but this one simply ties in with how things work now ...

Yes I do understand the issues with doing a hard fork - hell look at the mess caused by the way it was done back in April and that was a minor change ...

Ignoring Deepbit (especially since most of his miners don't understand or pay much attention to BTC) I'd actually expect most pools to be looking for a solution already and this solution in itself fits, code and design wise, well and easily into the current design.

It is also a long term solution
If someone thinks 4 billion times the current network isn't enough, then ok add two 32 bit nonce fields (for a total of 3) and I can't see that running out before BTC is completely redesigned some time in the far future.

1. Do you understand that this change will break every existing bitcoin client and service ?

2. ASIC may be "broken" even at the design or testing stage. It doesn't matters if this is BFL or not.

3. Breaking protocol (and possible ASICs, and possible hardware solutions like bitcoin smartcards and so on) without a reason is like waving a big sign "No serious business here" for most investors.

Doing a hard fork requires an exceedingly high level of consensus, as it requires everyone in the network to upgrade (not just miners). Unless there is a security flaw in the protocol, I doubt we'll see one anytime soon.

The problem you are complaining about is an efficiency problem for miners. I doubt you'll get a large percentage of the Bitcoin community to even accept this is a problem. At least in my opinion, it is not, as there are much more scalable solutions already available, such as local work generation.

Yeah I meant one that exists.

If bitcoin decisions are made based on unsubstantiated comments by companies like BFL - man are we in deep shit investing in BTC

Yes. Also we have other options: fast pool protocols and client-side work generation.

BFL SC, OpenASIC initiative, Vlad's something, Reclaimer.
Not to mention old Artforz's 350nm sASICs.

Um ... no.
https://bitcointalksearch.org/topic/difficulty-1-share-adoption-suggestion-for-pool-operators-89029

And when a device that hashes 100 times a 400MH/s GPU comes out - you really think the time field is appropriate? Seriously?

Name one ASIC miner ...

See BIP 22. It's a bit complex, but basically it allows moving the entire block-generation process to external processes, which only need to contact bitcoind to receive new transactions or blocks.

I don't think a hard fork is warranted for an efficiency problem for miners. When a fork comes, we can always consider extending the nonce of course...

We already have time rolling for this.
Adding another field is unacceptable since it will break ASIC miners.

It seems there are comments flying around about pools not being able to handle a larger network load with 1-difficulty shares caused by having devices that can hash 5/10/100 times faster, and that roll-n-time wont solve it.

So ... why not just add another 'nonce' 32 bit field after the current one?

Then pools and miners can use this as they see fit and I'm sure all the devs can understand how this will allow a single getwork to hash more shares or higher difficulty shares

The problem with roll-n-time is that each roll advances the block time into the future.
Instead, with a 2nd nonce field you can roll that field as many times as is valid and allowed by the pool (up to 4 billion times if hardware ever got that much faster)

Obviously getworks must still occur to add transactions into the work being processed, however, rigs that are able to process 100 times faster than your typical 400MH/s GPU will still only need the same number of getworks, not 100 times as many (with miner support of course) and with higher difficulty shares, less work will be returned also

So ... when's the fork gonna happen? Or will we wait until it's a critical problem ...