Author

Topic: A block-withholding miner... (Read 4747 times)

donator
Activity: 2058
Merit: 1054
August 26, 2013, 01: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.
newbie
Activity: 25
Merit: 0
August 07, 2013, 09:30:33 AM
#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.
full member
Activity: 220
Merit: 100
August 06, 2013, 10:48:31 PM
#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.

legendary
Activity: 952
Merit: 1000
August 06, 2013, 09:31:35 PM
#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
donator
Activity: 1218
Merit: 1079
Gerald Davis
August 06, 2013, 09:09:14 PM
#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.  
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
August 06, 2013, 08:50:14 PM
#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.
newbie
Activity: 37
Merit: 0
August 06, 2013, 05:37:07 PM
#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.
full member
Activity: 220
Merit: 100
August 06, 2013, 05: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.
cp1
hero member
Activity: 616
Merit: 500
Stop using branwallets
August 06, 2013, 04: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.
newbie
Activity: 37
Merit: 0
August 06, 2013, 04: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/)
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
August 03, 2013, 10:17:34 AM
#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.
legendary
Activity: 2058
Merit: 1452
August 03, 2013, 09:55:16 AM
#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.
-ck
legendary
Activity: 4088
Merit: 1631
Ruu \o/
August 03, 2013, 12: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.
full member
Activity: 725
Merit: 142
August 02, 2013, 08:02:53 PM
#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.
full member
Activity: 220
Merit: 100
August 02, 2013, 07:47:11 PM
#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?
Jump to: