Bitcoin Forum
November 08, 2024, 03:43:59 AM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: A block-withholding miner...  (Read 4742 times)
JoeMattie (OP)
Full Member
***
Offline Offline

Activity: 220
Merit: 100


View Profile
August 03, 2013, 12:47:11 AM
 #1

I just had a thought...

Wouldn't it be pretty trivial to modify a miner (cgminer for instance) so that (while pool mining) if a share is found that satisfies the requirements for a block, instead of submitting it to the pool, it sent it to a local solomining client which was listening for the same coin...

The pool would receive all the lower difficulty shares (and their associated payout(s)) and the unscrupulous miner would get the block reward...

Would there be any way to detect such behavior?

Bitrated user: AKQuaternion.
Winterfrost
Full Member
***
Offline Offline

Activity: 725
Merit: 142


View Profile
August 03, 2013, 01:02:53 AM
 #2

If I remember correctly, the pool keeps a secret key that must be combined with submitted work in order to be a valid block (or something similar to that). Obviously, if it were possible to withhold valid blocks then pool mining would be worthless unless you trusted every single miner in the pool.
-ck
Legendary
*
Offline Offline

Activity: 4284
Merit: 1645


Ruu \o/


View Profile WWW
August 03, 2013, 05:51:41 AM
 #3

Yes it's possible and in fact very easy to do. This is called a block withholding attack. If you are a on pay scheme on the pool based on some proportional pay scheme (true proportional, pplns, dgm etc) then you are penalising yourself since you will get paid less. If you are on a pay-per-share pay scheme only the pool stands to lose. The pool would have to have failsafes in where it randomly sent block solving shares to high hashrate miners to ensure they weren't doing this. It's not impossible, but I don't think any of the pools will tell you whether they do this or not, but I doubt they do.

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
grue
Legendary
*
Offline Offline

Activity: 2058
Merit: 1452



View Profile
August 03, 2013, 02:55:16 PM
 #4

[...]If you are on a pay-per-share pay scheme only the pool stands to lose. The pool would have to have failsafes in where it randomly sent block solving shares to high hashrate miners to ensure they weren't doing this.[...]
And what actions can the administrator take? The attacker can simply create more accounts, or disguise his hashrate by splitting among multiple pools.

It is pitch black. You are likely to be eaten by a grue.

Adblock for annoying signature ads | Enhanced Merit UI
-ck
Legendary
*
Offline Offline

Activity: 4284
Merit: 1645


Ruu \o/


View Profile WWW
August 03, 2013, 03:17:34 PM
 #5

I didn't say it was practical, feasible or infallible, and I also said I doubt any pool currently does it. This is why pools really need to think thrice about offering PPS and then not offer it anyway. At least there's a disincentive to mining on a proportionally based pay scheme, but if the pool hashrate is high enough, it's not a big enough disincentive. The only payscheme which offers a large enough disincentive to not do block withhold attacks is the PoT scheme (which coincidentally was my idea btw) at high diffs. Regardless, if someone wanted to sacrifice the income, they could do it on any payscheme to make a pool suffer.

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
optimiz3
Newbie
*
Offline Offline

Activity: 37
Merit: 0



View Profile
August 06, 2013, 09:33:59 PM
 #6

It's impossible, the Merkle Root in the block data encodes the transaction which assigns the reward to the pool.  There is no way to change the Merkle Root without invalidating the block.

Source: I develop Bitcoin Miner (http://www.groupfabric.com/bitcoin-miner/)
cp1
Hero Member
*****
Offline Offline

Activity: 616
Merit: 500


Stop using branwallets


View Profile
August 06, 2013, 09:42:42 PM
 #7

Yeah if you submitted a valid block to another pool the coinbase transaction would give the 25 BTC to the original pool anyway.

Guide to armory offline install on USB key:  https://bitcointalk.org/index.php?topic=241730.0
JoeMattie (OP)
Full Member
***
Offline Offline

Activity: 220
Merit: 100


View Profile
August 06, 2013, 10:35:37 PM
 #8

It's impossible, the Merkle Root in the block data encodes the transaction which assigns the reward to the pool.  There is no way to change the Merkle Root without invalidating the block.

Source: I develop Bitcoin Miner (http://www.groupfabric.com/bitcoin-miner/)

Hmm, who to believe...

I'd be willing to bet that ckolivas' bitcoin miner has a little more widespread adoption than yours...

Fuck it, I guess I'm gonna be spending the next few days reading code.

Bitrated user: AKQuaternion.
optimiz3
Newbie
*
Offline Offline

Activity: 37
Merit: 0



View Profile
August 06, 2013, 10:37:07 PM
Last edit: August 06, 2013, 10:52:16 PM by optimiz3
 #9

What? It has nothing to do with the miner, it's the Bitcoin spec.

EDIT #2: ckolvias and I aren't disagreeing - his point is a strategy for hurting the pool on certain payout strategies. Note that no less work is done, and no blocks are reassigned. My point is that you can't reassign blocks because it is built into the block protocol definition.
-ck
Legendary
*
Offline Offline

Activity: 4284
Merit: 1645


Ruu \o/


View Profile WWW
August 07, 2013, 01:50:14 AM
 #10

Actually I missed the part where you wanted to send it to your own bitcoind. I thought it was just the title "block-withholding miner". No you can't redirect your block data, you can just withhold it.

Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1079


Gerald Davis


View Profile
August 07, 2013, 02:09:14 AM
Last edit: August 07, 2013, 02:56:33 AM by DeathAndTaxes
 #11

Both ckolivas and optimiz are saying the same thing just in a different way.  Maybe this helps.  The nonce which solves a block only solves that specific EXACT block.  If you change anything, even a single bit it will produce a new different hash that will (almost always) be invalid.

Thus you can NEVER use a nonce that solves a blockheader created by the pool for any other purpose.  The pool/miner is rewarded by a transaction inside the block, if you change that, you change the block.  If you broadcast the block as is, well it doesn't matter who broadcasts it, the reward will go the the address(es) in the coinbase.

So
YES you can withhold a block from the pool.  In all pools except PPS this means your reward will go down as well as you are sharing a % of the total revenue produced by the pool and you have reduced the total revenue.  In a PPS pool your payment is fixed so it doesn't directly cost you anything but you don't gain directly either.  However if enough people did this the pool would eventually fail, the operators would lose, and you may need to go to a pool with less favorable terms. 

NO you can't "steal" the block reward, allow another pool to solve the block, or somehow gain any larger share of the reward.  
crazyates
Legendary
*
Offline Offline

Activity: 952
Merit: 1000



View Profile
August 07, 2013, 02:31:35 AM
 #12

NO you can't "steal" the block reward, allow another pool to solve the block, or somehow gain any larger share of the reward
Unless you're using PoT, in which case a block solver share is worth many times more than a regular share.

I totally agree with everything else you said; I'm just being a nitpicking ass.  Wink

Tips? 1crazy8pMqgwJ7tX7ZPZmyPwFbc6xZKM9
Previous Trade History - Sale Thread
JoeMattie (OP)
Full Member
***
Offline Offline

Activity: 220
Merit: 100


View Profile
August 07, 2013, 03:48:31 AM
 #13

Both ckolivas and optimiz are saying the same thing just in a different way.  Maybe this helps.  The nonce which solves a block only solves that specific EXACT block.  If you change anything, even a single bit it will produce a new different hash that will (almost always) be invalid.

Thus you can NEVER use a nonce that solves a blockheader created by the pool for any other purpose.  The pool/miner is rewarded by a transaction inside the block, if you change that, you change the block.  If you broadcast the block as is, well it doesn't matter who broadcasts it, the reward will go the the address(es) in the coinbase.

So
YES you can withhold a block from the pool.  In all pools except PPS this means your reward will go down as well as you are sharing a % of the total revenue produced by the pool and you have reduced the total revenue.  In a PPS pool your payment is fixed so it doesn't directly cost you anything but you don't gain directly either.  However if enough people did this the pool would eventually fail, the operators would lose, and you may need to go to a pool with less favorable terms. 

NO you can't "steal" the block reward, allow another pool to solve the block, or somehow gain any larger share of the reward.  

Okay, that makes sense.


Bitrated user: AKQuaternion.
Van3cespencer7
Newbie
*
Offline Offline

Activity: 25
Merit: 0


View Profile
August 07, 2013, 02:30:33 PM
 #14

I believe something like this has already happened in a pay per share pool. Forget the name but the miner withheld a block and the owner ended up taking out loans to pay his miners.

Lesson here pay per block.
Meni Rosenfeld
Donator
Legendary
*
Offline Offline

Activity: 2058
Merit: 1054



View Profile WWW
August 26, 2013, 06:01:17 AM
 #15

or somehow gain any larger share of the reward.  
You can gain a larger share of the reward, with the "lie in wait" withholding attack described in AoBPMRS and elsewhere.

1EofoZNBhWQ3kxfKnvWkhtMns4AivZArhr   |   Who am I?   |   bitcoin-otc WoT
Bitcoil - Exchange bitcoins for ILS (thread)   |   Israel Bitcoin community homepage (thread)
Analysis of Bitcoin Pooled Mining Reward Systems (thread, summary)  |   PureMining - Infinite-term, deterministic mining bond
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!