Pool Owner Keeping Generated Blocks?

[Obsi]

Hey, I've noticed some rather strange behavior at a pool recently, and I was wondering if there is any mechanism in place to prevent a pool owner from secretly keeping a generated block for himself or a way to find out if he is doing so?

Would it do anything other than make the pool look unlucky for the moment?

Is there any way to track which pool solved a block without relying on their own reported stats?

[error]

What strange behavior have you noticed, and at what pool?

[JoelKatz]

Hey, I've noticed some rather strange behavior at a pool recently, and I was wondering if there is any mechanism in place to prevent a pool owner from secretly keeping a generated block for himself or a way to find out if he is doing so?

To my knowledge, most pools don't provide you any way to detect this.

Would it do anything other than make the pool look unlucky for the moment?

That's what it would do. If the pool owner were clever, he could ensure only the miner who actually found the block could ever know.

Is there any way to track which pool solved a block without relying on their own reported stats?

Not unless you are the miner who solved the block. The pool hands out work units that only the pool and the miner who received them knows.

[SgtSpike]

And the plot thickens...

[Inaba]

Couldn't you track it via Blockexplorer and see if there are generated blocks that aren't showing up in the block list for that wallet? 

What method could be employed to provide proof of that barring blockexplorer?

I've actually been thinking along those lines as well, so I am also curious as to ways to prevent this/provide accountability.

One way to possibly detect it that couldn't really be forged is look at block generation history over time.  You'd be able to tell if something fishy is going on if their average/expected generation is not along a curve.  This would take a good number of blocks and I haven't done the math to know if a single block being "stolen" would affect the curve enough to be noticeable.

I wish there was some way to push out what block/wallet identifiable information with the Getwork.  Do you think this is something that's possible, Joel?

[SgtSpike]

Couldn't you track it via Blockexplorer and see if there are generated blocks that aren't showing up in the block list for that wallet? 

What method could be employed to provide proof of that barring blockexplorer?

I've actually been thinking along those lines as well, so I am also curious as to ways to prevent this/provide accountability.

One way to possibly detect it that couldn't really be forged is look at block generation history over time.  You'd be able to tell if something fishy is going on if their average/expected generation is not along a curve.  This would take a good number of blocks and I haven't done the math to know if a single block being "stolen" would affect the curve enough to be noticeable.

I wish there was some way to push out what block/wallet identifiable information with the Getwork.  Do you think this is something that's possible, Joel?

You can't track a wallet through blockexplorer.  You can only track addresses, and the generated blocks always use a new address for the BTC generated from them.  Unless you had a very sophisticated tracking algorithm, you won't be able to figure out which new blocks generated are related to a particular pool.  And even with an algorithm, you could only find the relationship if the BTC was spent in a similar manner (i.e. to many of the same payout addresses as a previous block, etc).

Block history won't tell you anything unless there is a major discrepancy in one of the largest pools.  There's a good deal of variance when it comes to block generation - you might see 10 blocks generated in an hour, then 2 the next.

[Inaba]

... Block chain attack?  That sounds like complete BS to me.  But I don't know the details so I am not dismissing it out of hand... but there is no way that I know of to target a "block chain attack" to a specific id.  If what SgtSpike says is accurate, and I have no reason to think it's not, then it's even more impossible since you'd never know in advance what address is going to generate the block.

[Jack of Diamonds]

Sounds like an admin-turned-greedy.  
I got burned in 2 small sub-20gh/s pools like that, the owner eventually ran after he got enough blocks

Then again, a 300 ghash/s pool doing this would be news

[Obsi]

Sounds like a scam & admin-turned-greedy. 
I got burned in 2 pools like that, the owner eventually ran after he got enough blocks

At recent prices I think many people may fall prey to greed. I think possibly a majority of people would walk away with a free $750ish dollars for the low low cost of making their pool look unlucky for a short while. Not to mention you'd have a heck of a time ever pinning the theft on them, so they wouldn't harm their own reputation much either.

PPS pools are starting to look better & better.

[JoelKatz]

They claim they are under some kind of blockchain attack, and have been deleting blocks they claim are invalid from their stats. This may very well be the case, but something seems fishy.

This could be an attack where they get bogus shares. If someone modified the pool controller without fully understanding the details, it can be possible to submit invalid shares and still have them count. For example, if they were getting too many shares and upped the difficulty only in the advertised difficulty to the client but not in the share checking logic, a miner who refused to honor their advertised difficulty would get credit for shares at the lower difficulty. This is an easy mistake to make.

It is also easy to mess up patches the reduce the number of stale shares reported to the miner. If you don't do this exactly right, you can give a miner credit for the same stale share if it's submitted more than once. The bitcoin client no longer tracks stale shares, so you have to do the code to count them yourself. It's surprisingly easy to mess that up. The bitcoin client does a lot of these checks by magic, they kind of just happen because of the way the code is structured. This could cause someone not familiar with C++ or boost to miss them -- and there's nothing to indicate how important they are since the client was designed on the assumption that the client trusts the miner.

That said, it could also be the pool scamming. But there are lot of ways to attack a pool that was customized by someone who doesn't understand the unique security issues of pooled mining. They could be going through that learning curve.

[Inaba]

Reading up on it a bit, their claim is that someone is attacking Bitcoind directly (via port 8333).  The details are sparse, but it sounds like the claim is that someone, somehow, gained access to the daemon and munged up their block chain.  I've been wracking my brain trying to think of a way this could possibly happen that wouldn't be self correcting on the next block, but I'm at a loss... though I do not know enough of how Bitcoind communciates on 8333 to know what's possible and what isn't.

[JoelKatz]

Reading up on it a bit, their claim is that someone is attacking Bitcoind directly (via port 8333).  The details are sparse, but it sounds like the claim is that someone, somehow, gained access to the daemon and munged up their block chain.  I've been wracking my brain trying to think of a way this could possibly happen that wouldn't be self correcting on the next block, but I'm at a loss... though I do not know enough of how Bitcoind communciates on 8333 to know what's possible and what isn't.

That should absolutely be impossible. If that is possible, it would indicate a serious bug in bitcoind.

The only way that would be possible is if someone snagged every single one of their connections. But bitcoind insists on sufficient outbound connections. So it should not be possible. And even if someone did, they would have to do an awful lot of work and would get nothing for it.

That sounds like BS to me. They should have talked to me first, I could have given them much more plausible explanations.

[SgtSpike]

Reading up on it a bit, their claim is that someone is attacking Bitcoind directly (via port 8333).  The details are sparse, but it sounds like the claim is that someone, somehow, gained access to the daemon and munged up their block chain.  I've been wracking my brain trying to think of a way this could possibly happen that wouldn't be self correcting on the next block, but I'm at a loss... though I do not know enough of how Bitcoind communciates on 8333 to know what's possible and what isn't.

These are the calls that can be made via port 8333:
https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list

Nothing that I see would munge up the blockchain.

EDIT:  Regardless, whoever generated block 136131 hasn't done anything with the coins from it yet...
http://blockexplorer.com/address/1FrTTPotXb9i1YS2XW9VJxniGoPiLSbDZC

[fpgaminer]

One way to possibly detect it that couldn't really be forged is look at block generation history over time.  You'd be able to tell if something fishy is going on if their average/expected generation is not along a curve.  This would take a good number of blocks and I haven't done the math to know if a single block being "stolen" would affect the curve enough to be noticeable.

This wouldn't work, even if "missing" blocks were statistically significant, because malicious miners not submitting network difficulty shares would cause the same effect. A network difficulty share being a share that also meets the current Bitcoin network difficult; i.e. this results in a block being found. Malicious miners can withhold these as an attack on the pool; the attackers still reap some reward, so the pool effectively pays for work not performed. This is most effective against PPS pools, because on proportional or other scoring systems you end up hurting yourself as well by not submitting blocks.

Back to the topic at hand: The only way I can think of combating pool-op scams is to add logging functionality to all the mining software, but even then all you could do is prove to yourself that the pool is cheating. You couldn't prove it to anyone else, because the logs can be forged.

Reading up on it a bit, their claim is that someone is attacking Bitcoind directly (via port 8333).  The details are sparse, but it sounds like the claim is that someone, somehow, gained access to the daemon and munged up their block chain.  I've been wracking my brain trying to think of a way this could possibly happen that wouldn't be self correcting on the next block, but I'm at a loss... though I do not know enough of how Bitcoind communciates on 8333 to know what's possible and what isn't.

That doesn't make any sense, and unless the pool-op gives a clear explanation of what is happening I would personally be cautious, though wouldn't jump to conclusions.

If an attacker can isolate a pool node from the real Bitcoin network, get it to only connect to the attacker's nodes, then they can block the transmission of new blocks to and from the pool. But I can't imagine a way of doing this; you have to prevent the pool from connecting to any legitimate nodes ...

EDIT:  Regardless, whoever generated block 136131 hasn't done anything with the coins from it yet...
http://blockexplorer.com/address/1FrTTPotXb9i1YS2XW9VJxniGoPiLSbDZC

Solo miner could have easily found it, and not spent it yet.

[SgtSpike]

EDIT:  Regardless, whoever generated block 136131 hasn't done anything with the coins from it yet...
http://blockexplorer.com/address/1FrTTPotXb9i1YS2XW9VJxniGoPiLSbDZC

Solo miner could have easily found it, and not spent it yet.

My point exactly.  Or heck, even a pool could have a separate wallet for payouts vs blocks income, and hasn't spent this one yet.

EDIT:  Really though, my point was that once those coins are on the move, we can potentially track where they are going.  Unlikely, but potentially.

[Obsi]

Decided to see if any of the bigger pools claimed 136131 in their stats.

BTCGuild (got 136130) doesn't claim it.
Deepbit (got 136132) doesn't claim it.
bitcoin.cz (slush) doesn't claim it.
Bitcoins.lc doesn't claim it.
btcmine doesn't claim it.
Eligius doesn't claim it.
mineco.in doesn't claim it.
Bitclockers doesn't look like they claim it, just has a timestamp, so kinda hard to tell.

That's a good bit of the graph at http://bitcoinwatch.com/
I'm sure there are plenty of solo miners that could have claimed it, or pools not listed.

But I think this is something every miner should keep in the back of his mind. If you aren't making something close to the number of bitcoins http://www.alloscomp.com/bitcoin/calculator.php says you should for the number of hashes you're putting out there, it might be time to evaluate the pools you use more closely.

[SgtSpike]

Decided to see if any of the bigger pools claimed 136131 in their stats.

BTCGuild (got 136130) doesn't claim it.
Deepbit (got 136132) doesn't claim it.
bitcoin.cz (slush) doesn't claim it.
Bitcoins.lc doesn't claim it.
btcmine doesn't claim it.
Eligius doesn't claim it.
mineco.in doesn't claim it.
Bitclockers doesn't look like they claim it, just has a timestamp, so kinda hard to tell.

That's a good bit of the graph at http://bitcoinwatch.com/
I'm sure there are plenty of solo miners that could have claimed it, or pools not listed.

But I think this is something every miner should keep in the back of his mind. If you aren't making something close to the number of bitcoins http://www.alloscomp.com/bitcoin/calculator.php says you should for the number of hashes you're putting out there, it might be time to evaluate the pools you use more closely.

And the plot thickens more...

[antares]

well, without wanting to raise a red flag, but I had my own experience on bitcoinpool - in fact when I was new, I started with them. When I tried to claim my first mined BTC I got "Permanently banned" for inefficiency - a friend of mine told me that they usually send warnings on this by mail, and I looked into it, but asides their spam there was nothing about inefficiency warnings. However, back then I decided for myself that they were probably right, and moved to another pool(bitcoins.lc) and I'm really happy there right now.

[BurningToad]

Actually, I can claim block 136131.  We found it at http://arsbitcoin.com  Our block numbers in the stats are off, because we use a very unsophisticated method of "what was the network block number when I checked to see if we solved a block".  Therefore, it shows up as block 136,133 on my site, because we only check for new blocks every 5 minutes or so.

    {
        "account" : "",
        "category" : "immature",
        "amount" : 50.18387175,
        "confirmations" : 25,
        "txid" : "4ac82717bba01fe64c79d8c68f76d54edeed867ebbbc5d718b98246f096edff9",
        "time" : 1310584156
    },

http://blockexplorer.com/tx/4ac82717bba01fe64c79d8c68f76d54edeed867ebbbc5d718b98246f096edff9

[Obsi]

Interesting, perhaps this will lead to a clarification of the attack being used against bitcoinpool and a correction of the problem. Thank you for letting us know BurningToad.

While I was researching this further I noticed bitcoinpool was run (or at least started) from a server in the founder's house, running over a fiber connection. Would this allow the blockchain to be poisoned through a MITM attack more easily since it isn't in a multi-homed datacenter?