Bitcoin Institute

How to overthrow the GPU Oligarchs

16 messages BitcoinTalk chickenado, Michael Marquardt, nelisky, TTBit, LZ, gebler, chrisdbc, kiba, Satoshi Nakamoto, FreeMoney October 1, 2010 — October 4, 2010
chickenado October 1, 2010 11:31 UTC

The strength of this project was meant to be its distributedness.

But now, it seems that an increasingly small and exclusive elite has taken charge of coin/block generation. It’s dominated by specialists who have access to wholesale means of production and secret, proprietary GPU code.

The average user no longer has a fighting chance and has given up generating blocks altogether.

What does this remind me of? That’s right, bitcoin is becoming like the physical money economy, where a small number of central banks now guarantee the trustworthiness of paper money.

There are two problems: One, the possibility of market manipulation, and more importantly, if only a handful of people do most of the proof of work, what is the point of a decentralized currency in the first place? It weakens us, because a powerful attacker would only need to bribe a few people to gain more than 50% of khash/s.

To stop this, I suggest the following:

  1. Add more hash functions that must be solved in addition to SHA-2. The more, the better. The function ecosystem should include functions with very different requirements, eg. some that require lots of memory, some that can’t be paralellized, some that require lots of disk space,… Also, function parameters that change randomly every time difficulty changes. This would take away some advantage from people who are highly specialized at solving just one hash function.

  2. Pooled block generation. For instance, if 100 users join a pool and one block is solved, the 50 coins are distributed among those users. This would encourage amateur users to start generating again.

Michael Marquardt (theymos) October 1, 2010 15:30 UTC
Quote from: chickenado on October 01, 2010, 11:31:46 AM UTC

But now, it seems that an increasingly small and exclusive elite has taken charge of coin/block generation. It’s dominated by specialists who have access to wholesale means of production and secret, proprietary GPU code.

The average user no longer has a fighting chance and has given up generating blocks altogether.

It’s always been the plan for block generation to not be profitable for most people. It’s supposed to be done mainly by dedicated “backbone” entities. What’s stronger: a thousand people producing 1 Gh/s with hardly any individual economic interest in preserving the network’s integrity, or five businesses producing the same Gh/s that will fail if they or someone else destabilizes the network?

I’m not saying that GPU code shouldn’t be made, but it’s not fair to say that GPU generators are “taking without giving back”. People dedicated to generating deserve a head-start on new technologies.

nelisky October 1, 2010 16:01 UTC
Quote from: theymos on October 01, 2010, 3:30:19 PM UTC
Quote from: chickenado on October 01, 2010, 11:31:46 AM UTC

But now, it seems that an increasingly small and exclusive elite has taken charge of coin/block generation. It’s dominated by specialists who have access to wholesale means of production and secret, proprietary GPU code.

The average user no longer has a fighting chance and has given up generating blocks altogether.

It’s always been the plan for block generation to not be profitable for most people. It’s supposed to be done mainly by dedicated “backbone” entities. What’s stronger: a thousand people producing 1 Gh/s with hardly any individual economic interest in preserving the network’s integrity, or five businesses producing the same Gh/s that will fail if they or someone else destabilizes the network?

I’m not saying that GPU code shouldn’t be made, but it’s not fair to say that GPU generators are “taking without giving back”. People dedicated to generating deserve a head-start on new technologies.

I was under the impression that coin generation was a way to make sure everyone had a fair chance of putting effort against coins, thus avoiding any central committee of deciding the future of bitcoins. Decentralized is the word, I believe…

But I get it, if you put the time and money into getting better miners, you should be able to keep it to yourself, so the 4way patch should never had been merged into mainline, as its creator would have 2x+ performance over the same machine running common clients.

I have to disagree here. Yes, competition is good and valuable, and people should not get into bitcoins for the mining alone, but if you let a small subset of people hold most of the future generated coins you are putting the whole project in danger of abuse and destruction… but I may be overreacting.

I’ll be glad to stop posting code, buy some serious hw and just do the generation myself. As difficulty goes up and people stop generating, this gets more and more statistically interesting… you say I should, right?

Michael Marquardt (theymos) October 1, 2010 16:12 UTC
Quote from: nelisky on October 01, 2010, 4:01:25 PM UTC

I’ll be glad to stop posting code, buy some serious hw and just do the generation myself. As difficulty goes up and people stop generating, this gets more and more statistically interesting… you say I should, right?

The network will eventually be run by “oligarchs”. Once software is optimized as far as it can be, it will come down to hardware, bandwidth, and, in the long-term, electricity generation. Most people won’t be able to keep up.

Posting GPU code now will just prolong the period when generation is feasible for normal people. This will attract a few users, and it might increase the network’s total power on the short-term, but on the long-term it’ll have little value. If I were you, I’d keep the code private. Publishing it wouldn’t be bad for the network, though.

TTBit October 1, 2010 16:15 UTC

Start a pool yourself. If you are generating 4000k/sec 10 others are generating 20,000k/sec combined, you get 4,000/24,000 of each block generated. Seems this code could be introduced. I don’t think the GPU Oligarchs are making a mint, in fact, I bet they are losing money to my benefit.

I bet you could pay nelisky for proprietary code yourself. But, the economics won’t work out.

Michael Marquardt (theymos) October 1, 2010 16:22 UTC

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.

chickenado October 1, 2010 17:03 UTC
Quote from: theymos on October 01, 2010, 4:12:31 PM UTC

The network will eventually be run by “oligarchs”. Once software is optimized as far as it can be, it will come down to hardware, bandwidth, and, in the long-term, electricity generation. Most people won’t be able to keep up.

It will if proof-of-work comes down to something as specialized as solving a single, well-defined, simple, and predictable hash function such as SHA-2.

We need to make proof-of-work more choatic and complex if we want to avoid this. 

SHA-2 was actually designed to be computationally EASY because it’s original purpose was digital signing, not proof-of-work. 

Otherwise, it will end just like you say.

Think of this vision of the year 2020: 2/3 of the world’s Ghash/s is controlled by just three companies. They manufacture their own specialilsed HPUs (hash processing units) and feed them with custom-built power plants. The Chinese goverment then persuades the three companies to double spend 10% of all transactions into the Chinese government’s bitcoin address, in return the companies get an exclusive deal on the rare earths they badly need for the HPU manufacture. Some people leave Bitcoin for alternative currencies without the 10% “tax”, but most tolerate it because by then Bitcoin is accepted almost universally.

LZ October 2, 2010 05:49 UTC

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

Michael Marquardt (theymos) October 2, 2010 06:11 UTC
Quote from: lzsaver on October 02, 2010, 5:49:47 AM UTC

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

gebler October 3, 2010 18:03 UTC
Quote from: theymos on October 02, 2010, 6:11:11 AM UTC

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 October 3, 2010 20:08 UTC

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 October 3, 2010 20:12 UTC
Quote from: chrisdbc on October 03, 2010, 8:08:33 PM UTC

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 Nakamoto October 3, 2010 21:30 UTC
Quote from: theymos on October 02, 2010, 6:11:11 AM UTC
Quote from: lzsaver on October 02, 2010, 5:49:47 AM UTC

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 October 4, 2010 00:52 UTC
Quote from: kiba on October 03, 2010, 8:12:03 PM UTC
Quote from: chrisdbc on October 03, 2010, 8:08:33 PM UTC

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 October 4, 2010 01:27 UTC
Quote from: chrisdbc on October 04, 2010, 12:52:11 AM UTC

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

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

kiba October 4, 2010 01:50 UTC
Quote from: FreeMoney on October 04, 2010, 1:27:24 AM UTC
Quote from: chrisdbc on October 04, 2010, 12:52:11 AM UTC

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.