Mining cartel attack | Bitcointalksearch.org

mootinator

sr. member

Activity: 274

Merit: 250

Quote from: safeminer on November 05, 2013, 09:48:44 AM

Before this kind of attack gets interessting to any one party that could afford to do it right now, it would be too expensive.
Say they pump a million USD into mining gear and get a significant amount of the network. Imagine half of every other miner out there plugging in an extra bitfury because they see their rewards have dropped.
The whole chunk they just bought for a million dollar would be useless again.

The cynical assumption the article makes is not that any one party could afford to do it, but rather that huge masses of existing equipment people overpaid for would willingly jump to a pool offering this strategy in order to recoup costs.

safeminer

member

Activity: 110

Merit: 10

Before this kind of attack gets interessting to any one party that could afford to do it right now, it would be too expensive.
Say they pump a million USD into mining gear and get a significant amount of the network. Imagine half of every other miner out there plugging in an extra bitfury because they see their rewards have dropped.
The whole chunk they just bought for a million dollar would be useless again.

krach

legendary

Activity: 1851

Merit: 1020

Get Rekt

This article is being spread around facebook and co
http://hackingdistributed.com/2013/11/04/bitcoin-is-broken/

slush

legendary

Activity: 1386

Merit: 1097

Quote from: FreddyFender on January 03, 2011, 04:25:36 AM

278 seconds to find block 100810
9 seconds to find block 100809
52 seconds to find block 100808
88 seconds to find block 100807
342 seconds to find block 100806

Well, people are suspicious when pool find blocks too fast, they are suspicious when pool find blocks too slow; You probably need block exactly every 3-4 hours, right? :-)
I found two block in a row with single 5970, so numbers above for 5ghash pool are not so exciting for me. It is only kind of luck.

Edit: Oh, sorry, now I see those blocks are not generated by pool. I was confused because FreddyFender submitted this comment also to pool thread.

slush

legendary

Activity: 1386

Merit: 1097

Quote

as slush said his server came under a DDoS attack last week....hrm...

Stop this conspiracy. DDoSed was completely another service, not pool itself. And I already know who was the attacker - it was my colleague (tester), playing with new version of performance testing tool. Yes, he was so dumb that he pointed testing tool @ 100mbit line to my poor personal VPS :-/.

FreddyFender

full member

Activity: 215

Merit: 100

Shamantastic!

278 seconds to find block 100810
9 seconds to find block 100809
52 seconds to find block 100808
88 seconds to find block 100807
342 seconds to find block 100806

Are the cartels onto something here or is this an anomaly?

Found something that can check SW state of large HPCs.

InstantCheck: Checking the Determinism of Parallel Programs Using On-the-fly Incremental Hashing
http://www.upcrc.illinois.edu/media/publications.html
This could graph changes to SW or running programs by comparing previous hashes of software runs (Deterministic replay).
It might be useful to see who is monkeying with codebase and trying to game the system.
Simple change to isStandard() would allow reporting to all generators and cartels... but this is future stuff not needed for beta Undecided

"Determinism is generally deﬁned as producing observationally equivalent outputs on
all executions starting from observationally equivalent inputs"
https://researcher.ibm.com/researcher/files/us-mtvechev/SAS%202010%20-%20Determinism.pdf

isStandard() detects scout tx
creates test tx and watches IO then creates hash (worker) that reports to generators nodes (hives)
compares to previous hash for inconsistencies, cool!

I would like to see the java on this but I don't think it is FOSS.

Dakus

newbie

Activity: 3

Merit: 0

Quote from: FairUser on January 02, 2011, 10:05:31 PM

Can you plz link to that thread?

No, I didn't create a thread, I just said that I was searching a thread to ask the same question. Sorry for my English, I was misunderstood.

Quote from: MoonShadow on January 02, 2011, 11:37:59 PM

Quote from: FairUser on January 02, 2011, 12:32:31 AM

Explain how a 6 minute delay occurs before my bitcoin client on my windows box sees the block count get updated after it was solved on my other PC (yes, I found the block for the bitcoin pooled mining).

I can't answer this one.

I doubt that somebody can.

More interesting examples from http://nullvoid.org/bitcoin/statistix.php?showallblocks:
-383 seconds to find block 100597
-54 seconds to find block 100671
-58 seconds to find block 100697

MoonShadow

legendary

Activity: 1708

Merit: 1010

Quote from: FairUser on January 02, 2011, 12:32:31 AM

Quote from: MoonShadow on January 02, 2011, 12:02:47 AM

Quote from: FairUser on January 01, 2011, 10:08:56 PM

Several blocks are found in less than 1-2 minute, some even have been found in negative time (like block 100557 found in -19 seconds). Today it seemed like many of the blocks are being found well underneath the average time.

I also noticed that when the mining pool @ bitcoin.cz got a block, my windows Bitcoin client didn't get notified of the block update for 6 minutes!
That means the Pool got a 6 minute head start of everyone else @ 5.5 Bhash/s ... that's a good head start. I'm not sure what caused this behavior, but it was interesting to watch happen before your eyes. Go figure, the bitcoin pool got several blocks after that too, then didn't get any for several hours.

I doubt that there is anything untoward happening here. The timestamps in the blocks are based off of the generating machine's clocktime, which can vary considerably. Even if it's being attempted by someone, it's not detrimental to the network.

I'm not talking about the blocks time stamps. I saying I sat in front of my PC, watched the pool get a block, noted the time on MY desktop, and 6 minutes later (again on my desktop) my bitcoin client updated it's block count by 1.

To be clear, my windows client is just being used to monitor when blocks go up or when I generate coins.
My Linux box has the GPUs in it, and is contributing to the pool.

When the bitcoin.cz pool got a block, it was 6 minutes before my windows client saw the update. WHY???

Explain how a 6 minute delay occurs before my bitcoin client on my windows box sees the block count get updated after it was solved on my other PC (yes, I found the block for the bitcoin pooled mining).

I can't answer this one.

FairUser

sr. member

Activity: 1344

Merit: 264

bit.ly/3QXp3oh | Ultimate Launchpad on TON

Quote from: Dakus on January 02, 2011, 07:24:49 AM

Quote from: FairUser on January 01, 2011, 10:08:56 PM

I also noticed that when the mining pool @ bitcoin.cz got a block, my windows Bitcoin client didn't get notified of the block update for 6 minutes!

Just started to search a thread to put about the same question to the BTC community. Huh

Can you plz link to that thread?
Thx

Dakus

newbie

Activity: 3

Merit: 0

Quote from: FairUser on January 01, 2011, 10:08:56 PM

I also noticed that when the mining pool @ bitcoin.cz got a block, my windows Bitcoin client didn't get notified of the block update for 6 minutes!

Just started to search a thread to put about the same question to the BTC community. Huh

FairUser

sr. member

Activity: 1344

Merit: 264

bit.ly/3QXp3oh | Ultimate Launchpad on TON

Quote from: MoonShadow on January 02, 2011, 12:02:47 AM

Quote from: FairUser on January 01, 2011, 10:08:56 PM

Several blocks are found in less than 1-2 minute, some even have been found in negative time (like block 100557 found in -19 seconds). Today it seemed like many of the blocks are being found well underneath the average time.

I also noticed that when the mining pool @ bitcoin.cz got a block, my windows Bitcoin client didn't get notified of the block update for 6 minutes!
That means the Pool got a 6 minute head start of everyone else @ 5.5 Bhash/s ... that's a good head start. I'm not sure what caused this behavior, but it was interesting to watch happen before your eyes. Go figure, the bitcoin pool got several blocks after that too, then didn't get any for several hours.

I doubt that there is anything untoward happening here. The timestamps in the blocks are based off of the generating machine's clocktime, which can vary considerably. Even if it's being attempted by someone, it's not detrimental to the network.

I'm not talking about the blocks time stamps. I saying I sat in front of my PC, watched the pool get a block, noted the time on MY desktop, and 6 minutes later (again on my desktop) my bitcoin client updated it's block count by 1.

To be clear, my windows client is just being used to monitor when blocks go up or when I generate coins.
My Linux box has the GPUs in it, and is contributing to the pool.

When the bitcoin.cz pool got a block, it was 6 minutes before my windows client saw the update. WHY???

Explain how a 6 minute delay occurs before my bitcoin client on my windows box sees the block count get updated after it was solved on my other PC (yes, I found the block for the bitcoin pooled mining).

MoonShadow

legendary

Activity: 1708

Merit: 1010

Quote from: FairUser on January 01, 2011, 10:08:56 PM

Several blocks are found in less than 1-2 minute, some even have been found in negative time (like block 100557 found in -19 seconds). Today it seemed like many of the blocks are being found well underneath the average time.

I also noticed that when the mining pool @ bitcoin.cz got a block, my windows Bitcoin client didn't get notified of the block update for 6 minutes!
That means the Pool got a 6 minute head start of everyone else @ 5.5 Bhash/s ... that's a good head start. I'm not sure what caused this behavior, but it was interesting to watch happen before your eyes. Go figure, the bitcoin pool got several blocks after that too, then didn't get any for several hours.

I doubt that there is anything untoward happening here. The timestamps in the blocks are based off of the generating machine's clocktime, which can vary considerably. Even if it's being attempted by someone, it's not detrimental to the network.

FairUser

sr. member

Activity: 1344

Merit: 264

bit.ly/3QXp3oh | Ultimate Launchpad on TON

Quote from: bfever on December 15, 2010, 06:05:32 PM

In my opinion, the timestamp of a block doesn't give any information on whether the block was generated and released immediately to the rest of the network or not.

Consider the following case:

The current block chain has N blocks at time T0.
The "cartel" finds a new block "N+1", let's call it block X, at a certain time T1 and decides not to publish it right away.
Some time later at T2, somebody not inside the cartel finds also a block "N+1" (call it block Y) and releases it immediately to the rest of the network.
Once one of the cartel nodes see this block Y, the whole cartel releases block X (and doesn't transmit block Y to other nodes).

What does an honest node see at time T3 (seconds later then T2): it gets (at best) two new solutions X and Y and it has to decide which one is "the best" to start working on. If it would rely on the timestamp T1 and T2 of the blocks, block X will win each time, as it was created (well) before block Y !
As the difficulty is adjusted so that blocks are generated in average every 10 minutes, T1 and T2 won't be hours apart either (but probably between 0 to 30 minutes).

So the cartel has two advantages: it is already working for the time T2-T1 on block N+2 (and if it has already been found, it can destroy block Y instantly by publishing block N+2 too) and it can prevent transmitting "non-cartel" blocks to other nodes to a certain degree.

I believe you hit the nail on the head here. I believe this could be happening right now.
Look real closely at some of the stats @ nullvoid, http://nullvoid.org/bitcoin/statistix.php?showallblocks

Several blocks are found in less than 1-2 minute, some even have been found in negative time (like block 100557 found in -19 seconds). Today it seemed like many of the blocks are being found well underneath the average time.

I also noticed that when the mining pool @ bitcoin.cz got a block, my windows Bitcoin client didn't get notified of the block update for 6 minutes!
That means the Pool got a 6 minute head start of everyone else @ 5.5 Bhash/s ... that's a good head start. I'm not sure what caused this behavior, but it was interesting to watch happen before your eyes. Go figure, the bitcoin pool got several blocks after that too, then didn't get any for several hours.

I'm also curious if the bitcoin pools are being messed with by said "cartels", as slush said his server came under a DDoS attack last week....hrm...

inertia

newbie

Activity: 35

Merit: 0

http://inertia.posterous.com/bitcoin-mining-cartels-a-total-non-threat

MoonShadow

legendary

Activity: 1708

Merit: 1010

You might be able to leverage this technique to gain an advantage over the network with less than 50% of total processor power under certain ideal conditions; but you will still need something very close to 50% even if your attack conditions are perfect. It's also an attack vector that is unsustainable, as the first non-cartel block to get accepted by the network breaks any prior computational advantage and renders the cartel's prior work towards the next block based upon their delayed block worthless. In the end, I would say that the conditions required to make this work would be nearly as difficult for any group as simply aquiring the resources to take 50% of the network. Either way it's at a nation-state level already, and we are not a particularly large network.

bfever

jr. member

Activity: 39

Merit: 1

In my opinion, the timestamp of a block doesn't give any information on whether the block was generated and released immediately to the rest of the network or not.

Consider the following case:

The current block chain has N blocks at time T0.
The "cartel" finds a new block "N+1", let's call it block X, at a certain time T1 and decides not to publish it right away.
Some time later at T2, somebody not inside the cartel finds also a block "N+1" (call it block Y) and releases it immediately to the rest of the network.
Once one of the cartel nodes see this block Y, the whole cartel releases block X (and doesn't transmit block Y to other nodes).

What does an honest node see at time T3 (seconds later then T2): it gets (at best) two new solutions X and Y and it has to decide which one is "the best" to start working on. If it would rely on the timestamp T1 and T2 of the blocks, block X will win each time, as it was created (well) before block Y !
As the difficulty is adjusted so that blocks are generated in average every 10 minutes, T1 and T2 won't be hours apart either (but probably between 0 to 30 minutes).

So the cartel has two advantages: it is already working for the time T2-T1 on block N+2 (and if it has already been found, it can destroy block Y instantly by publishing block N+2 too) and it can prevent transmitting "non-cartel" blocks to other nodes to a certain degree.

btchris

hero member

Activity: 672

Merit: 504

a.k.a. gurnec on GitHub

Quote from: nanotube on December 14, 2010, 05:18:32 PM

...
to run the "reject other blocks" attack, as i understand it, i'll generate a block but keep it to myself, while continuing to work on generating a block that builds on top of my hidden block.

so, let's say that I generated a block. now, i have two choices. choice one - i release it to the network, and claim my 50btc, and start working on my second block, which i then later also release and claim my next 50 btc.

choice two - i keep it hidden, and work on generating another block building on top of my secret block, all the while the rest of the network is still toiling away on the first block. in order for me to make the network 'waste power', in other words, in order to be able to trash the rest-of-network's block, i need to be able to generate another block after the rest-of-network generates one block, but before the rest of the network generates two blocks.
...

In order to make the network 'waste power', you only need two things:

Keep at least one solved block to yourself for any amount of time, and
somehow do you best to later get that block into the chain, even though you're not releasing it right away.

If you can accomplish both of these goals (the second goal being the difficult one), you slow down the rest of the network without slowing down your own processing power, and so you end up with relatively more processing power compared to the rest of the network.

The attacks being discussed, as I understand them, ask the questions:

What if you release your hidden block as soon as the rest of the network releases its next block? There will be a race which you might be able to win, but how often and is it worth it?
Same question, but is it possible to find a way (e.g. lots of connections to lots of other clients) to increase the chances that your just released block will get into the chain, and the competing block will not?
If you happen by chance to get additional blocks ahead of the network (which is likely to happen on occasion), can you use this to further your advantage?

I'm not sure if question #2 has been answered, but if it is possible for a cartel to give itself a networking advantage, it appears to gain a mining advantage even if it's a not-so-big cartel. Even if #2 is not possible, ByteCoin has a simulation where #3 is regardless a problem (although you have to be a pretty big cartel to pull it off).

theymos

administrator

Activity: 5222

Merit: 13032

Quote from: jcw9 on December 14, 2010, 05:39:20 PM

So part of the computed input to the hash is a rounded version of the current time. If Bitcoin had something like this (and I'm sure there's some messy mechanics involved), it would allow us to reject blocks that have been stored for longer than a day (in this example). I suppose a cartel could precompute blocks in the future and hold them till they become valid / useful, but if the range for this were say, 4 hours?

There already is a timestamp, and you already will reject blocks too far in the past or future.

jcw9

newbie

Activity: 3

Merit: 0

There's a solution to a participant withholding blocks that is used by Hashcash:

Quote

The recipient's computer checks the date in that header "060408" (8 Apr 2006). If it's within 2 days of today, it's valid (to compensate for clock skew and routing time).

So part of the computed input to the hash is a rounded version of the current time. If Bitcoin had something like this (and I'm sure there's some messy mechanics involved), it would allow us to reject blocks that have been stored for longer than a day (in this example). I suppose a cartel could precompute blocks in the future and hold them till they become valid / useful, but if the range for this were say, 4 hours?

mpkomara

full member

Activity: 183

Merit: 100

I feel that ByteCoin is right. However, a counterattack:

If the network suspects a cartel, there are several strategies to make life harder for the cartel. here is my idea.

At the expense of some unlucky honest block generators, impose a time restriction of, say, 20 seconds before any two blocks can be accepted by a node.

Cartel finds block 1 and 2 before the rest of the network does. Say an honest generator finds block 1 and immediately transmits the message to the rest of the network. The cartel matches by sending block 1, but the cartel now has to wait 20 seconds before they can transmit block 2. If an honest generator finds block 2 in that 20 seconds, they too will wait until the 20 seconds is up. I'm not sure that 20 seconds is the right number, but it at least forces the cartel into more races. The cartel will necessarily have a lower fraction of blocks if the network adopts this strategy.

Topic: Mining cartel attack (Read 31959 times)