Pages:
Author

Topic: How to attack Bitcoin mining? (Read 2738 times)

legendary
Activity: 3878
Merit: 1193
August 23, 2014, 03:43:40 PM
#30
More generally, what if I participate in a pool and just keep the good hashes for myself? I guess this would be strictly more profitable for me than just participating in a pool. But if every one does the same, pools should just never find a block. Right? Then: Why do pools exist in the first place?

You can't "keep the good hashes". Either you send them to the pool, or you throw them away. If you throw them away, you get nothing. Yes, you can do that, but it's a waste for you.
newbie
Activity: 32
Merit: 0
August 23, 2014, 03:04:29 PM
#29
More generally, what if I participate in a pool and just keep the good hashes for myself? I guess this would be strictly more profitable for me than just participating in a pool. But if every one does the same, pools should just never find a block. Right? Then: Why do pools exist in the first place?
newbie
Activity: 27
Merit: 0
August 19, 2014, 03:57:32 PM
#28
There is so much Wrong information here that goes against everything I thought.

Maybe what you thought was incorrect not the information presented.  Google "block withholding attack" it has been known and discussed for years.  It is pretty much as old as pooled mining.

Quote
3. Client solves the new "problem" (Important; Client dont know if their solution works on "complicated problem" as client dont have that)

This is incorrect.  A miner instantly knows if he solved a block or not.  However that solution is tied to that specific attempted block (with predetermined coinbase or "reward" address).  A miner can't profit from this information.  He can either submit it or not submit it.  Not submitting it is the block withholding attack.  This will reduce the profitability of all miners in the pool including the attacker.  The amount of the reduction is directly related to the blocks withheld so if a miner has 5% of the pool hashrate and withholds half the blocks he solves then all miners (inlcuding the attacker) will earn 2.5% less than expected.

There are potential ways to make the block withholding attack impossible however they would require a hard fork in the protocol.



Yeah well I alone could think of ways to close this hole so if there is a hole it is just the lazy devs or the stubborn bitcoiners that havent implemented it yet.
donator
Activity: 1218
Merit: 1079
Gerald Davis
August 19, 2014, 03:53:54 PM
#27
There is so much Wrong information here that goes against everything I thought.

Maybe what you thought was incorrect not the information presented.  Google "block withholding attack".  It has been know and discussed pretty much as long as there has been pooled mining.

Quote
3. Client solves the new "problem" (Important; Client dont know if their solution works on "complicated problem" as client dont have that)

This is incorrect.  A miner instantly knows if he solved a block or not.  However that solution is tied to that specific attempted block (with predetermined coinbase or "reward" address).  A miner can't profit from this information.  He can either submit it or not submit it.  Not submitting it is the block withholding attack.  This will reduce the gross revenue produced by the pool and will equally affect all miners in the pool (including the attacker) and the pool operator.

There are ways to make the block withholding attack impossible however they require a hard fork in the protocol (a change in the format of the block header).
mjc
hero member
Activity: 588
Merit: 500
Available on Kindle
August 19, 2014, 03:46:56 PM
#26
There is so much Wrong information here that goes against everything I thought. Im pretty sure it works this way:

1. Pool has "complicated problem" to find a new block
2. Pool takes part of this "complicated problem" and sends to client
3. Client solves the new "problem" (Important; Client dont know if their solution works on "complicated problem" as client dont have that)
4. Client sends in the solution
5. Pool checks to see solution works on the given problem
6. If solution works GOOD POOL FOUND NEW BLOCK! if not it still had a chance to find the solution. Either way the client gets payed
7. Pool sees how often you submit a solution to decide what your hashrate approx is.

This also means that it takes some time for the pool to calc your computer speed fx. your computer submits 100 solutions an hour and the pool
calc's this into 10G/Hash (JUST EXAMPLE).


Today I learned: If I took a lot of computers to mine in pool and started to withhold possible solutions, the pool would see it as the hashrate was dropped as you are normally paid per successful solutions send to pool.

Or maybe im just stupid and bitcoin is very easy to kill.

When you sit with a solution you have no idea if pool can use it or not (Neither does pool yet), you know that there is a much bigger chance of this being the solution the pool can use than if you took a random answer. You only get paid when you submit it to the pool.

So in a nutshell you're suggesting that you cannot chain pools together.  If this is accurate than the OP claim of vulnerability has been resolved as False.
mjc
hero member
Activity: 588
Merit: 500
Available on Kindle
August 19, 2014, 03:45:19 PM
#25
Do you even have the slightest idea about how important Bitcoin Mining!!! and you want to attack it!!! Why!!!

Because of the importance of mining is exactly why we should talk about the vulnerabilities associated with it.  It is only then that we can mitigate them and strengthen Bitcoin.

Michael, CEH & OSCP
Security Pen Tester
newbie
Activity: 27
Merit: 0
August 19, 2014, 03:30:47 PM
#24
There is so much Wrong information here that goes against everything I thought. Im pretty sure it works this way:

1. Pool has "complicated problem" to find a new block
2. Pool takes part of this "complicated problem" and sends to client
3. Client solves the new "problem" (Important; Client dont know if their solution works on "complicated problem" as client dont have that)
4. Client sends in the solution
5. Pool checks to see solution works on the given problem
6. If solution works GOOD POOL FOUND NEW BLOCK! if not it still had a chance to find the solution. Either way the client gets payed
7. Pool sees how often you submit a solution to decide what your hashrate approx is.

This also means that it takes some time for the pool to calc your computer speed fx. your computer submits 100 solutions an hour and the pool
calc's this into 10G/Hash (JUST EXAMPLE).


Today I learned: If I took a lot of computers to mine in pool and started to withhold possible solutions, the pool would see it as the hashrate was dropped as you are normally paid per successful solutions send to pool.

Or maybe im just stupid and bitcoin is very easy to kill.

When you sit with a solution you have no idea if pool can use it or not (Neither does pool yet), you know that there is a much bigger chance of this being the solution the pool can use than if you took a random answer. You only get paid when you submit it to the pool.

For children:


Imagine that your parents had this rare football.
They just didnt know where this rare football was.
So they paid you to bring them round objects.
Everytime you bought them a round object you get paid a little.
The parents could not tell you that it is the football they are looking for,
if they told you and you found it, you would keep it too your self.
so they tell you to bring them round objects, now you dont know if your parents actually profit when you bring them a round object.

You bring them a tennisball
you bring them a tire
you bring them a melon

It might take long but in time and with enough people someone will bring the football, they will give it too the parents because it has no value to them, they dont know it is rare, all they know is that it is a round object.

The parents sell the football and use the money the pay the children for each round object they found.

Really hard to put it more simple sorry.

Now there are different systems.

Named PPS, PPLNS and so on.

In some systems the children are payed per thing they submit that qualify.

In others no one is payed until the football is found and then they are payed equal to effort.

sometimes the children might get lucky and find the football after just 4 things have been submitted and the 4 people all share the reward. (Thus getting payed much to be lucky)

Other times there will go along time without anyone finding what item is actually worth anything, in this case the people will get payed litle when you consider the number of possible things they have submitted.



ITS all about who takes Variance that the pool or the miners.

Overtime thou it shouldn't matter.

sr. member
Activity: 476
Merit: 250
August 18, 2014, 08:22:52 PM
#23
Step 4)  Don't submit winning hashes, reducing the REVENUE of competitors by 3%

When mining you don't know if you have the winning hash until after you submit it (sometimes not even then).

Neil
There are some modified versions of mining software (I believe it was cgminer) that can be set so that found blocks are not submitted to the pool. There was a miner in China earlier this year that was mining on the eligius pool, withheld what should have been several blocks (they would have been expected to find several blocks verses what they actually found); it ended up costing the pool several hundred BTC. There was also likely a similar attack on BTC guild that lasted several months before that as their luck was way below what it should have been.
donator
Activity: 1617
Merit: 1012
August 18, 2014, 06:02:49 PM
#22
Would this work, is this a threat at all?
It is hard to say. The community would be closely watching such a pool and would likely take countermeasures the moment that pool does any underhanded stuff. This may include custom clients that would completely prevent blocks solved by that pool from propagating through the network, if such blocks could be identified easily.
legendary
Activity: 896
Merit: 1000
August 18, 2014, 04:46:54 PM
#21
Step 4)  Don't submit winning hashes, reducing the REVENUE of competitors by 3%

When mining you don't know if you have the winning hash until after you submit it (sometimes not even then).

Neil

Hi Neil, thanks for the input. This is the latest response I've got from BM on the forum  https://bitsharestalk.org/index.php?topic=7003.msg94085#msg94085

Your absolutely right of coarse, the miner could 'guess' what shares may solve a block without too much trouble.

Neil

P.S. I blame a head cold, I took some pseudoephedrine about an hour or two ago and I just realized I am not thinking all that straight.... I think I will stop doing test restores of VM's as well before I do some damage Tongue .
sr. member
Activity: 299
Merit: 253
August 18, 2014, 04:07:45 PM
#20
Maybe it's also possible to mine for two pools at the same time?

Would like to have a wiki article on attack vectors on mining operators where these questions are answered.

When mining you don't know if you have the winning hash until after you submit it (sometimes not even then).

I thought so, but how does that actually work?
newbie
Activity: 6
Merit: 0
August 18, 2014, 04:01:43 PM
#19

Oh and withholding shares can be be detected with some smart heuristics.

That sounds like it may be an answer, why this can't work thanks!


I asked about the 'smart heuristics' on the BitShares forum scorchingsun,


If you divide your attack hash power among 1000 accounts, then the probability that any one of those accounts would find a block in a given a given year is effectively 0.  No way to distinguish "unlucky" from "withholding" without a large enough sample size.   Keep the accounts small enough and you will be undetectable.   (Sybil Attack)

If someone like BCX, who seems to know his stuff, could give me a simple answer why this attack wouldn't work I would greatly appreciate it. Thanks!

You may be right about that, I'm not that firm in the theory. But in order to mine at other pools or pools at the same time, they'd need you to find a solution for the same Bitcoin address as the coinbase (not the company) address.
member
Activity: 97
Merit: 10
Inch by Inch,Play by Play
August 18, 2014, 03:54:28 PM
#18
interesting stuff, waiting to read more!
legendary
Activity: 1138
Merit: 1001
August 18, 2014, 03:35:53 PM
#17
Step 4)  Don't submit winning hashes, reducing the REVENUE of competitors by 3%

When mining you don't know if you have the winning hash until after you submit it (sometimes not even then).

Neil

Hi Neil, thanks for the input. This is the latest response I've got from BM on the forum  https://bitsharestalk.org/index.php?topic=7003.msg94085#msg94085

You know if your hash might produce a block.

You are not "submitting billions of hashes to the pool" you are only submitting hashes below a certain threshold.  Simply don't return any hash below the current block chain difficulty to the pool.

You still end up submitting a lot of "work shares" but no "work shares" that might qualify as a winning hash.

It is impossible for the pools to efficiently distribute the "search process" while keeping the target of the search a "secret".   The miner needs to know they found the "secret" before they decided to broadcast it to the pool.  Because the miner is the one who knows the hash first and must DECIDE to broadcast then the miner is in control.

Effectively everyone who mines "work shares" but never shares anything that could also claim a block is earning income from the pool without actually helping to secure the network or increasing the Bitcoin difficulty.  

An attacker who can mine more efficiently than everyone else can perform this attack on the network.

Suppose the average profitability of miners is 5% and someone is able to mine with 10% margins.   They can attack the pool by doing "negative mining".  With "negative mining" they will "earn 5%" while their competitors are forced to eat losses or stop mining all together.  

With positive mining you end up increasing the bitcoin difficulty and pushing out competition.  With negative mining you end up decreasing the bitcoin difficulty while earning the same profit.  

Bitcoin difficulty is a function of the profitability of mining.  When mining in a pool it is a function of the pool payout.   If the attacker can reduce the payout of all public pools, then it will reduce the profitability of all small miners to the point where they stop mining and the network difficulty drops.  

The end result is that all pools must go private or have very stringent verification processes for people to join the pool.


legendary
Activity: 4424
Merit: 4794
August 18, 2014, 03:03:31 PM
#16
I'm not that technical. But I've seen this approach being discussed on the BitShares forum as perhaps a weakness of POW.
Would this work, is this a threat at all?

Step 1)  Buy 3% of the hash power (secretly)
Step 2)  Set up a mining pool that merge mines Namecoin (or other alts) and auto sells for BTC, thus charging a negative fee
Step 3)  Once your pool has enough hash power (3-4%), point your secret hash power at top mining pool
Step 4)  Don't submit winning hashes, reducing the REVENUE of competitors by 3%
Step 5)  Continue to subsidize your pool with BTC earned from competitors pools

Result: Competitors pools become unprofitable and your pool is the only profitable option, your pool gets 51%

Step 6) Randomly Orphan blocks produced by other pools (cutting into their profits more, increasing your hash power further as people are forced to join your pool or eat losses on their hardware investment)

The cost of the attack is an order of magnitude cheaper than buying 51% hash power and assumes only that a large number of miners are in this to earn profits today and not to hold BTC.   You appeal to their short-term greed, their thin margins, or their cash flow constraints to force them to join you to avoid losses.  

The only way to combat this is to have 51% of the hash power in private pools.


in short no..

2) if your pools is charging different miners negative fee, then your not making income
3) if your attempts to on the other pool your equipment was on, did actually succeed in preventing them making blocks.. your simply stopping yourself getting paid too...
4) every miner is not submitting winning hashes thousands of times a second.. all hashes are losers until (average tenth minute) one single hash is the winner. thus your not doing any damage,
5) as described in (3)(4) you cant subsidize YOUR pool if you are not making any funds from the other pools..

6) a 3% hashrate farm wont make a blind bit of difference.. all your doing is wasting your own funds and costing yourself alot of wasted time, for nothing.

but goodluck trying it.
legendary
Activity: 1260
Merit: 1019
August 18, 2014, 02:53:13 PM
#15
When mining you don't know if you have the winning hash until after you submit it (sometimes not even then).
Wrong.
https://bitcointalk.org/?topic=441465.msg7282674#msg7282674
legendary
Activity: 896
Merit: 1000
August 18, 2014, 02:45:30 PM
#14
Step 4)  Don't submit winning hashes, reducing the REVENUE of competitors by 3%

When mining you don't know if you have the winning hash until after you submit it (sometimes not even then).

Neil
member
Activity: 112
Merit: 10
August 18, 2014, 02:42:40 PM
#13
Do you even have the slightest idea about how important Bitcoin Mining!!! and you want to attack it!!! Why!!!

I don't want to attack it! Half my alt-coin investment is in Bitcoin! However if someone says it may be possible to attack Bitcoin with 3/4% of the hashing power, I'd like to understand why it's wrong.

To me it seemed like, (To keep the numbers simple)...

----
- If there were a $1 Billion in new coins made a year then a pool with 30% hash power could expect to earn $300 million in revenue.

- However Bitcoin margins are tight. How tight? I don't know but I doubt they're making more than $15-30 million profit.

- If 3% secret hash power (or 10% of the pool) was not submitting winning hashes, it would take $30 million of revenue from them, making them unprofitable.

- As you're part of their pool though you would still receive a 97% payout,  $27 million. So you may be at a loss too but only a $1 million or two and for that you get to make the main mining pool unprofitable.

- Hashers would leave the main unprofitable pool for the one a bad intentioned person controls, which could then easily accumulate 51% hashing power.
----

Oh and withholding shares can be be detected with some smart heuristics.

That sounds like it may be an answer, why this can't work thanks!


First post didn't make sense to me, this post makes way more sense as to what you're saying.
Interesting idea, scorchingsun says you could find those withholding finds, but would this be efficient?
hero member
Activity: 601
Merit: 500
Vote 4fryn :)
August 18, 2014, 02:35:31 PM
#12
That's something like: how to get rich
1) Use time machine to go back in time
2) Buy BTC
3) sell in 2020.
In theory it works, but in reality not really.
How about the person who posted it in the forum tries it and see what happens.

I COULD be done easier than that^ just still not really.
legendary
Activity: 1260
Merit: 1019
August 18, 2014, 02:21:04 PM
#11
Quote
do a 51% attack on Bitcoin or build a big mining pool like Ghash
1) and what next?
2) ghash already uses merged mining

Quote
reducing the REVENUE of competitors by 3%

Quote
(I don't get the country analogy, sounds interesting, but it went over my head I'm afraid.)

To win in a modern competition in economics you should not drop bombs and have the largest military forces.
The only thing you should do is reducing the revenue of competitors.
This can be done by printing your currency and spread it to a pool miners native citiziens (negative fee, budget deficit)
Analogy: bitcoin=gold, namecoin=dollar, community=world, your miners=us citizens, 1492...2014 and so on
Pages:
Jump to: