Bitcoin Forum
November 13, 2024, 11:23:30 AM *
News: Check out the artwork 1Dq created to commemorate this forum's 15th anniversary
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: A +50% pool can grab bc from others  (Read 1830 times)
udibr (OP)
Newbie
*
Offline Offline

Activity: 36
Merit: 0


View Profile
May 15, 2011, 04:39:06 AM
 #1

A 55% pool can coordinate their work and agree to continue to mine a block for one additional minute after a similar block was already found by a none member miner.
The pool also agree that if suc a delayed block is found they will continue to use it in the next block.
Finally the pool agree to abandon this branch if they are out computed for a second time in a row.

Let's see: it takes the pool to generate a new block at a little bit less that 20 min.
So they have a +5% chance of finding a block in the 1min.
The none members already started working on next block and in 10min they will find it,
The pool has only 9min but is bigger so there is about an equal chance for them to compute the second block first. When that happens the pool get bc of both blocks.
So income was doubled for giving up 10% of the time by adding the 1min
iya
Member
**
Offline Offline

Activity: 81
Merit: 10


View Profile
May 15, 2011, 05:36:04 AM
 #2

I'm not sure if you are mistaken about the minute numbers or used them just illustratively. Finding a block can take from seconds to hours.
As the probability of solving any block is constant (while the difficulty is constant), the 55% pool has no advantage if it continues to work on the old block.
Except if you're thinking in terms of the total finite number of blocks, but even then the 45% miners have again their fair chance to solve the next two blocks.
So the 55% pool will, on average, mine 55% of all blocks and not more.
error
Hero Member
*****
Offline Offline

Activity: 588
Merit: 500



View Profile
May 15, 2011, 06:35:35 PM
 #3

So you're saying the 55% pool can force a reorg and invalidate blocks from the minority?

3KzNGwzRZ6SimWuFAgh4TnXzHpruHMZmV8
Gavin Andresen
Legendary
*
Offline Offline

Activity: 1652
Merit: 2301


Chief Scientist


View Profile WWW
May 15, 2011, 11:05:49 PM
 #4

Yep, if you control more than 50% of the hashing power you can just refuse to work on anybody else's blocks and your chain will always eventually be the longest.

Of course, if you do that there will be constant block chain splits and transaction confirmations will take twice as long (because you'd be throwing away the other half of the network's hashing power), so we'd all notice.

And I'm pretty confident we'd think of an effective way to ignore your blocks.  Seems like an awfully big risk for a +50% pool operator to take; why would they want to undermine the system that is (almost certainly) making them lots of money?

How often do you get the chance to work on a potentially world-changing project?
unk
Member
**
Offline Offline

Activity: 84
Merit: 10


View Profile
May 15, 2011, 11:12:34 PM
 #5

the error that economic forces undermine an attack dates back to satoshi's paper and ought to be seen clearly as a mistake by now. i posted a link to this excellent analysis at fatwallet in another discussion: http://www.fatwallet.com/forums/finance/1090435/m15945892/#m15945892
udibr (OP)
Newbie
*
Offline Offline

Activity: 36
Merit: 0


View Profile
May 16, 2011, 12:33:40 AM
 #6

the idea is that a pool can once in while grab the 50bc that were rightly owned to a none member.
Doing it in a way that undermines the entire system.
Since it is impossible to know for sure who are the pool members then any time a split happens (and they do) then it could be a sign of illegal grabbing.
iya
Member
**
Offline Offline

Activity: 81
Merit: 10


View Profile
May 16, 2011, 12:55:44 AM
 #7

Yep, if you control more than 50% of the hashing power you can just refuse to work on anybody else's blocks and your chain will always eventually be the longest.

But you will never be able to create a chain in which you own more blocks than your share of total hashing power.
There is no incentive to reject a solved block, and if you do, why would it undermine the entire system?
udibr (OP)
Newbie
*
Offline Offline

Activity: 36
Merit: 0


View Profile
May 16, 2011, 01:45:57 AM
 #8

for one thing there is a limited supply of 50bc blocks that is going to end soon.
So you want to force yourself to take control of all these blocks before the network switches to 25bc blocks.
gigitrix
Hero Member
*****
Offline Offline

Activity: 630
Merit: 500



View Profile
May 16, 2011, 01:52:03 AM
 #9

It's a very temporary problem: I'm hoping to see a lot more competition in the pool space, and this issue won't arise, even when pools go down for 10 minutes. It's only due to Bitcoin's infancy that the "auxiliary technology" industry is lagging behind. Same with the lack of commerce support I think: as the software becomes robust, we'll see more in this space.

We need to see an open source pool server: that would create waves within the industry and encourage competition, splitting the monolithic pools that threaten to pass 50%.

I should add that there's nothing malevolent about anyone currently approaching 50%, there's just obviously a lack of competition.
iya
Member
**
Offline Offline

Activity: 81
Merit: 10


View Profile
May 18, 2011, 02:53:24 AM
 #10

I wanted to rectify my previous statement that you cannot create a chain with more than your share of blocks.
What threw me of was "Finally the pool agree to abandon this branch if they are out computed for a second time in a row."
With >50% you can obviously create your own chain, if you never include a different block.
This would also halve the effective hashing power and block creation rate.

Since the miners in the smaller share would notice this very quickly, they would be pretty much forced to join the big pool.
Then the biggest threat becomes the attractiveness of a double spend attack, for example on Mt Gox.

As this is not in the interest of the miners, the best solution seems to be for members of a big pool to start their own smaller pool.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!