(quoted post by LZ)

Can you tell more about this: “they have to do weird things with extraNonce, which increases the size of the block header”.

Quote from: lzsaver on October 02, 2010, 05:49:47 AM

Can you tell more about it: “they have to do weird things with extraNonce, which increases the size of the block header”.

When you generate, you calculate hashes of the block header. Hashing more data is slower than hashing less data, so the block header is critically of a fixed size for everyone, with one exception. After every hash attempt, you increment the Nonce header field, but since this field is only 32 bytes long, it overflows a lot. Whenever it overflows, you increment the variable-size extraNonce field. The larger extraNonce gets, the slower generating will get. It doesn’t get significantly large with normal incrementing, though.

If you have a lot of computers and they’re all working on the same block with the same public key, then they’re all very likely to be hashing the same block at the same time, which is pointless. To fix this, each computer is given a unique extraNonce modifier value. This might be very large to prevent collisions, and it therefore slows down hashing.

Undoubtedly you could design a pooling system without this flaw, but it’d be more difficult.

I see that m0mchil’s getwork is doing something with extraNonce. I don’t know how bad that implementation is, but it theoretically must be slower than a client without it (all things being equal; clearly adding GPU support will improve performance).

Quote from: theymos on October 02, 2010, 06:11:11 AM

If you have a lot of computers and they’re all working on the same block with the same public key, then they’re all very likely to be hashing the same block at the same time, which is pointless. To fix this, each computer is given a unique extraNonce modifier value. This might be very large to prevent collisions, and it therefore slows down hashing.

In a centralized system, the server could simply keep a list of extraNonces in active use and give out the lowest free one. Then you would avoid collisions without requiring more than one unique extraNonce per client. A 3-byte extraNonce would be sufficient for millions of clients. Note that clients of realistic performance do not really need the extraNonce to handle nonce overflow today, since such overflows happen less frequently than the periodic nTime updates (but this is not considered by the standard client today, which updates the extraNonce more liberally).

I’m just getting into this whole bitcoin thing. It seems to me already, though, that getting great results from bitcoin mining would require a server farm, super computer, etc; worrying about individuals taking advantage of their GPUs or crypto accelerators is probably pointless. What can 30000 khash/s really get you? Maybe around the equivalent of $1.50 per day at current difficulty levels? Not really a very efficient means of recouping the cost of an expensive gaming rig.

I’d be much more concerned about what somebody with a botnet might be capable of.

Quote from: chrisdbc on October 03, 2010, 08:08:33 PM

I’d be much more concerned about what somebody with a botnet might be capable of.

So what if a botnet generate all these bitcoins? He’ll be able to move markets for his money. Big deal.

Quote from: theymos on October 02, 2010, 06:11:11 AM Quote from: lzsaver on October 02, 2010, 05:49:47 AM

Can you tell more about it:

“they have to do weird things with extraNonce, which increases the size of the block header”. When you generate, you calculate hashes of the block header. Hashing more data is slower than hashing less data, so the block header is critically of a fixed size for everyone, with one exception.This is the point of confusion.  extraNonce is not part of the block header, it is part of the first transaction.  It does not slow down your hashing.  It does not change the size of the header.

We need to be vigilant and nip in the bud any misconception that the contents of your block slows down your hash speed.  It doesn’t.

extraNonce never needs to be very big.  We could reset it every second whenever the time changes if we wanted.  Worst case, if you didn’t want to keep track of incrementing it, extraNonce could be 4 random bytes and the chance of wasting time from collision would be negligible.

Separate machines are automatically collision proof because they have different generated public keys in the first transaction.  That also goes for each thread too.