Topic: Guild pool a 51% threat? (Read 8867 times)

Not that the last comment has anything at all to do with Bitcoin ...

But if you were mining BTC ... with the original cgminer ... you simply need to mine multiple reliable pools (yeah there really are only a few )
and loadbalance them so you mine all at the same time.

This will also reduce your payout variance if you aren't mining PPS (not the fake PPS pools that are affected by block finding)

Alright... seriously, you revived two posts over 2 years old each and posted exactly the same reply to each.  What's the deal?  Just felt the need to find old posts that mentioned pools that might hit that magical 51% mark?

Miners could voluntarily, do a small fractional amount of pool hopping,
For example, with BfgMiner, I can set up 5 Pools to mine at regular intervals, eg 1 hr each, or 1day each.
If 4 of those were the same pool and 1 were a different pool, then this would reduce my hashing power being sent to a big pool by 20%
They probably wouldn't lose very much if anything by this method, they might get lucky for that period and earn more.
They could even strengthen the network by making one of those pools a P2P pool.
Miners can voluntarily make a difference to the 51% problem.

Not that I'm mining very much with my 1.3 MH Gaw Scrypt Zeusminer 

That's also my impression. Well, I am a newbie, and I am sure this is easier suggested than implemented, but why not solve this problem with technical means?  e.g. let the mining clients check if their pool gives them a block of legitimate transactions to work on.

As far as I recall we've lived with such a situation for quite a long time: deepbit has had around 50% (sometimes above) for long periods of time. I didn't like it back then and I don't like it now, but it's not "terrifying".

Except that you don't need a majority of the hashrate to perform it.

"majority attack"

This was a really helpful post, gmaxwell. It made a nice and easy read of the ideas behind this type of attack - you might consider stickying the essentials somewhere.

It might also be an idea if someone renamed this attack to something that doesn't include the number "51" in the name.

There was a post on this subject on bitcoin-development last night, but it hasn't shown up in the archives yet.

Here was my response:

On Fri, Apr 5, 2013 at 2:30 AM, Melvin Carvalho
<[email protected]> wrote:
> There was some chat on IRC about a mining pool reaching 46%
> http://blockchain.info/pools

The estimates on there may be a bit lossy.

> What's the risk of a 51% attack.

The whole fixation on "51" as a magic number is a bit confused— I'll
say more below.

> I suggested that the pool itself is decentralized so you could not launch
> one

None of the pools listed there are meaningfully decentralized—  before
Luke whines, in theory the ones supporting GBT could be if used in a
way that no one actually uses them.  P2Pool is decentralized based on
the same technology as Bitcoin itself, but it's certainly not as point
and click easy as a centralized pool.

> On IRC people were saying that the pool owner gets to choose what goes in
> the block

That is correct.

Though I'd point out— the major pool ops all seem to be great folks
who care about the future of Bitcoin— and the continued success of
their very profitable businesses: a 50% mining pool with a 3% fee
rakes in 54 BTC per _day_.

The more likely threat isn't that pool owners do something bad: It's
that their stuff gets hacked (again) or that they're subjected to
coercion. ... and the attacker either wants to watch the (Bitcoin)
world burn, or after raiding the pool wallet can't exploit it further
except via blockchain attacks.

> Surely with random non colliding nonces, it would be almost impossible to
> coordinate a 51% even by the owner

That makes no sense. A centralized pool is the miner, the remote
workers are just doing whatever computation it tells them to do.
Certainly these remote workers might switch to another pool if they
knew something bad was happening... but evidence suggests that this
takes days even when the pool is overtly losing money.  Miners have
freely dumped all their hashpower on questionable parties (like the
infamous pirate40) with nary a question as to what it would be used
for when they were paid a premium for doing so.  It seems even those
with large hardware investments are not aware of or thinking carefully
about the risks.

> It would be great to know if this is a threat or a non issue

It's important to know exactly what kind of threat you're talking
about—  someone with a large amount of hash-power can replace
confirmed blocks with an alternative chain that contains different
transactions. This allows them to effectively reverse and respend
their own transactions— clawing back funds that perhaps had already
triggered irreversible actions.

This doesn't require some magic "51%"— its just that when a miner has
>50% the attack would always be successful if they kept it up long
enough (long enough might be years if you're talking really close to
50% and he gets unlucky). Likewise, someone with a sustained
supermajority could deny all other blocks— but that attack's damage
stops when they lose the supermajority or go away.

More interesting is this:  An attacker with only 40% of the hashpower
can reverse six confirmations with a success rate of ~50%. There is
source for computing this at the end of the Bitcoin paper.   I did a
quick and really lame conversion of his code JS so you can play with
it in a browser:

https://people.xiph.org/~greg/attack_success.html

Thus removing the problem once and for all. derp?

Create better pool. You will take away a lot of users from BTC Guild ;-)

Well tbh. giving one pool 25% of the hashrate is more than I'd like to see, the current situation is terrifying.

This isn't the first time a single pool has made 6 blocks in a row, nor will it ever be the last.  Ozcoin did it before with less than 25%.  BTC Guild is only at 35% of the last 2016 blocks.  That's a LONG way off of 51%.  ~10 TH/s would have to leave other pools and join BTC Guild (extremely unlikely), or ~15 TH/s of new speed would have to join the network and all point at BTC Guild (even less likely).

6 Blocks in a row ..this is irresponsible.

Miners still using getwork would be kicked off, thus removing ~15% of BTC Guild's total speed, because ~3-4 TH/s worth of users continue to use getwork.  I still doubt it's going to be needed.  Guild has yet to actually reach 40%, so a lot of these "51%" posts have been a bit premature.

How would it remove ~15%?

It would remove ~15% of the pool's hash power, including the part of the pool that contains the most undetected botnets, which is yet another plus for getting rid of getwork.  However, I don't think it will be needed.  BTC Guild is still under 40% at this time.

What exactly would that do? Boot off all GPU miners? Im still aimed at 8332

mtred?

the 0 fee PPS pool has never approached 51%, it opened in June 2011