Bitcoin Forum
September 29, 2016, 05:00:41 PM *
News: Latest stable version of Bitcoin Core: 0.13.0 (New!) [Torrent]. Make sure you verify it.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 [3]  All
  Print  
Author Topic: Mining cartel attack  (Read 26858 times)
mpkomara
Full Member
***
Offline Offline

Activity: 180



View Profile
December 14, 2010, 10:20:58 PM
 #41

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.

"Governments are good at cutting off the heads of a centrally controlled networks like Napster, but pure P2P networks like Gnutella and Tor seem to be holding their own." -- Satoshi
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
jcw9
Newbie
*
Offline Offline

Activity: 3


View Profile
December 14, 2010, 10:39:20 PM
 #42

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?
theymos
Administrator
Legendary
*
Offline Offline

Activity: 2422


View Profile
December 14, 2010, 10:50:07 PM
 #43

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.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
btchris
Hero Member
*****
Offline Offline

Activity: 560

a.k.a. gurnec on GitHub


View Profile WWW
December 14, 2010, 11:51:53 PM
 #44

...
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).
bfever
Jr. Member
*
Offline Offline

Activity: 39


View Profile WWW
December 15, 2010, 11:05:32 PM
 #45

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.


Use your freedom, use bitcoins !

Bitcoin Relational Database (in MySQL) aka The BiRD now available.
Universal Bitcoin Smartcard coming soon.

UBiCard - BiRD donations: 1UbicardpLQiAhGfEWKaV5xnKkmgzj1Ce
MoonShadow
Legendary
*
Offline Offline

Activity: 1666



View Profile
December 15, 2010, 11:16:54 PM
 #46

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.

"The powers of financial capitalism had another far-reaching aim, nothing less than to create a world system of financial control in private hands able to dominate the political system of each country and the economy of the world as a whole. This system was to be controlled in a feudalist fashion by the central banks of the world acting in concert, by secret agreements arrived at in frequent meetings and conferences. The apex of the systems was to be the Bank for International Settlements in Basel, Switzerland, a private bank owned and controlled by the world's central banks which were themselves private corporations. Each central bank...sought to dominate its government by its ability to control Treasury loans, to manipulate foreign exchanges, to influence the level of economic activity in the country, and to influence cooperative politicians by subsequent economic rewards in the business world."

- Carroll Quigley, CFR member, mentor to Bill Clinton, from 'Tragedy And Hope'
inertia
Jr. Member
*
Offline Offline

Activity: 34



View Profile WWW
December 20, 2010, 06:03:53 PM
 #47

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

You should try my Minecraft server.
FairUser
Sr. Member
****
Offline Offline

Activity: 261


View Profile WWW
January 02, 2011, 03:08:56 AM
 #48

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...
MoonShadow
Legendary
*
Offline Offline

Activity: 1666



View Profile
January 02, 2011, 05:02:47 AM
 #49

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.

"The powers of financial capitalism had another far-reaching aim, nothing less than to create a world system of financial control in private hands able to dominate the political system of each country and the economy of the world as a whole. This system was to be controlled in a feudalist fashion by the central banks of the world acting in concert, by secret agreements arrived at in frequent meetings and conferences. The apex of the systems was to be the Bank for International Settlements in Basel, Switzerland, a private bank owned and controlled by the world's central banks which were themselves private corporations. Each central bank...sought to dominate its government by its ability to control Treasury loans, to manipulate foreign exchanges, to influence the level of economic activity in the country, and to influence cooperative politicians by subsequent economic rewards in the business world."

- Carroll Quigley, CFR member, mentor to Bill Clinton, from 'Tragedy And Hope'
FairUser
Sr. Member
****
Offline Offline

Activity: 261


View Profile WWW
January 02, 2011, 05:32:31 AM
 #50

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

Dakus
Newbie
*
Offline Offline

Activity: 3


View Profile
January 02, 2011, 12:24:49 PM
 #51

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
****
Offline Offline

Activity: 261


View Profile WWW
January 03, 2011, 03:05:31 AM
 #52

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
MoonShadow
Legendary
*
Offline Offline

Activity: 1666



View Profile
January 03, 2011, 04:37:59 AM
 #53

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.

"The powers of financial capitalism had another far-reaching aim, nothing less than to create a world system of financial control in private hands able to dominate the political system of each country and the economy of the world as a whole. This system was to be controlled in a feudalist fashion by the central banks of the world acting in concert, by secret agreements arrived at in frequent meetings and conferences. The apex of the systems was to be the Bank for International Settlements in Basel, Switzerland, a private bank owned and controlled by the world's central banks which were themselves private corporations. Each central bank...sought to dominate its government by its ability to control Treasury loans, to manipulate foreign exchanges, to influence the level of economic activity in the country, and to influence cooperative politicians by subsequent economic rewards in the business world."

- Carroll Quigley, CFR member, mentor to Bill Clinton, from 'Tragedy And Hope'
Dakus
Newbie
*
Offline Offline

Activity: 3


View Profile
January 03, 2011, 08:25:47 AM
 #54

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.


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
FreddyFender
Full Member
***
Offline Offline

Activity: 215


Shamantastic!


View Profile
January 03, 2011, 09:25:36 AM
 #55

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

slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
January 03, 2011, 03:30:43 PM
 #56

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 :-/.

slush
Legendary
*
Offline Offline

Activity: 1358



View Profile WWW
January 03, 2011, 03:33:58 PM
 #57

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.

krach
Legendary
*
Offline Offline

Activity: 1092


"every thought has a sound"


View Profile WWW
November 05, 2013, 12:36:46 PM
 #58

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

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
    Haasbot Bitcoin Trade Bot
             Automate Bitcoin and Altcoin Trades              Over 10 Exchanges ● 500+ Altcoins
    ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
safeminer
Member
**
Offline Offline

Activity: 107



View Profile WWW
November 05, 2013, 02:48:44 PM
 #59

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.

my bitcoin blog:  http://j.gs/2q9l
mootinator
Sr. Member
****
Offline Offline

Activity: 272


View Profile
November 05, 2013, 03:43:56 PM
 #60

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.

Alms for the middle class: 1Mootin8RQCHwb53zm3GTHNxBJfjRkUT15
TTC: TTyCoin4Fep8mEyKPv8uTNgiUtqjiPJ55n
Pages: « 1 2 [3]  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!