How to overthrow the GPU Oligarchs

[LZ]

Thash's? http://cube20.org/

[MoonShadow]

How many Ghash's do you think Google would do if it started to generate?

Probably all of them, but difference would it make?  Even if they are willing to commit the full brunt of their computing resources to overtake the generation of new coins, they can't make them faster than the difficulty system would permit.  At least not for more than two weeks.  Nor can they do anything to manipulate the value of the coins already in existance, beyond the effects of the regular generation awards.  That's the beauty of the design, even Google couldn't do more than disrupt the system temporarily.  Even at this early stage, the total proof-of-work represents a supercomputing class cluster.  For what gain would anyone do such a thing?  For a max return of 50K coins over two weeks of supercomputing time?  Even Google doesn't have the computing power to rebuild the blockchain from the beginning.  Even if they did, to what end?  To steal a quarter million dollars in wealth?  Which would likely collapse the system if it could be done at all, so that value would drop to zero.  As we have seen, that difficulty level increases as the user base increases, regardless of an analysis as to the economics of each person generating.

I can accept that, however unlikely, a takeover of the system is possible; but if such a thing were to happen, it certainly wouldn't go unnoticed by the Bitcoin community.  From where I stand, the odds that the Federal Reserve will cease to exist and the FRN collapse is more likely to occur first.  For that matter, I would consider a worldwide extinction-level-event to be about as likely; but I'm not going to let the risks of a meteor strike stop me from walking out on the surface of the Earth.

[asdf]

Pools won't eliminate the "problem" because pools are not more profitable than normal generation; they just pay out more often. They can't beat companies that have invested in specialized hardware. They also delegate all of the important network decisions to the pool maintainer, so there's no security benefit.

Pools offer the advantage that nodes can co-ordinate their hashing so that they aren't generating the same hashes as each other. It's not about "total hash/s", it's about "total unique hash/s". If everyone in the pool is assigned a subset of all hashes to work on (sizes based on each nodes average hash/s), then we'll guarantee that no hashes will be repeated. The node that generates the coin can just keep the full amount. The group will be better off together than alone. The bigger the pool, the better. In fact if these pools get much bigger than the companies (in terms of hash/s), then THEY will be severely marginalized and be forced to join the main pool or get nothing.

If the pool gets too big, then coins may be generated almost instantly at some point. This could be bad for the stability of the currency. Can anyone do the math on how many parallel coperating cpus it would take to find a coin in say, one minute?

I think this is a very important issue for the success of Bitcoin.

[theymos]

Pools offer the advantage that nodes can co-ordinate their hashing so that they aren't generating the same hashes as each other. It's not about "total hash/s", it's about "total unique hash/s". If everyone in the pool is assigned a subset of all hashes to work on (sizes based on each nodes average hash/s), then we'll guarantee that no hashes will be repeated.

This is already guaranteed because everyone has a unique public key in their block. You reminded me of another way that pools are bad, though: since everyone uses the same public key, they have to do weird things with extraNonce, which increases the size of the block header and makes generating more difficult for them.

[LZ]

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

[FreeMoney]

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

Usually you can start the nonce at 0 because they block you are working on is made unique by the inclusion of your unique address in the generate transaction. If a group of people all send generates to the same address you need another number included to make sure that the members are not repeating work.

I have no idea how important that fact is, it doesn't seem like too big of a deal to me, but theymos can elaborate.

[theymos]

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

[chickenado]

Even Google doesn't have the computing power to rebuild the blockchain from the beginning.  Even if they did, to what end?  To steal a quarter million dollars in wealth?  Which would likely collapse the system if it could be done at all, so that value would drop to zero. 

They wouldn't need to rebuild the blockchain from the beginning. They can double spend any transaction that happens after the 50% Ghash/s takeover. Of course, if they get too greedy, the system would collapse as users become fed up with their coins being stolen all the time. But what if they decide to double spend a certain "optimal income" percentage of transactions, just short of what will piss off most users?

[grondilu]

Non issue, imo.

Those guys are just working for us.  I'll just buy their bitcoins.  It will probably be cheaper than buying expensive hardware and running it 24/24.

By selling bitcoins those might think they screw us.  I think they're just wrong.

[gebler]

The larger extraNonce gets, the slower generating will get.

But that effect would be totally insignificant.  Even the standard client is optimized so that it doesn't need to hash the entire block header if only the last part of it has changed.  That last part includes the nonce but not the extraNonce, so a larger extraNonce wouldn't cost anything for the vast majority of all hashes, namely those where only the normal nonce has been incremented.  With today's transaction volumes, the cost of hashing the extraNonce should be less than a millionth of a percent for pools with thousands of members. 

[gebler]

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

[chrisdbc]

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.

[kiba]

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.

[satoshi]

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.

[chrisdbc]

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.

It's certainly a big deal to steal other's resources to generate bitcoins.

[FreeMoney]

It's certainly a big deal to steal other's resources to generate bitcoins.

Look, it's still true without the bitcoin part.

[kiba]

It's certainly a big deal to steal other's resources to generate bitcoins.

Look, it's still true without the bitcoin part.

I suspect it's more profitable to run a email scam than to generate bitcoin.

[MoonShadow]

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.

It's certainly a big deal to steal other's resources to generate bitcoins.

And there is nothing we can do about that.

[chrisdbc]

I suspect it's more profitable to run a email scam than to generate bitcoin.

Probably true. There are likely many other more efficient ways of illegally
making money.

[thesavoyard]

I suspect it's more profitable to run a email scam than to generate bitcoin.

Probably true. There are likely many other more efficient ways of illegally
making money.

They had no idea....