Bitcoin Forum

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?

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

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

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.

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.

And the plot thickens...

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.

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

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

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.

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.

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

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

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.

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

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.

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

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.

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

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?

I don't know what different that would make. Probably none.

No.

To make a more general statement:

With a bit of dedication currently EVERY single pool owner could snag a block every once in a while and call it bad luck. If he's a little bit clever (using a seperate wallet to make sure these coins don't get mixed with pool payouts etc.) that's an easy task. Something like that would be 100% undetectable and even easier for bigger pools that find blocks en masse.

The solution to this would be to let miners decide + see which transactions to include.

Doesn't do wonders for transparency IMO :| People are right to do due diligence and be paranoid because blocks really have been missing on some pools like bitcoins.lc (admins have so far decided to pay them out promptly though after being notified of the fact)

Esp. for bigger miners, a 'few missing blocks here and there' can mean a lot of lost money.
(Ars is a good legit pool, just saying in general)

Not if the pool has a pure PPS payment scheme (no shared maximum or other experiments)
Then keeping blocks becomes irrelevant because you get paid for every single share regardless of round length.

So far I've only seen deepbit stand up to the challenge. Their fee is a bit steep though.

We have PPS (see sig) but we're pretty new and so the trust issue is pretty large I guess. We do charge a fee for it (7%, less than deepbit) but it might be reduced after we build up a BTC buffer for ourselves against 10-million share rounds.

It's not as fishy as you think it is. I suspect bitcoinpool has a buggy hashrate display. It was already discussed on their forums, and I'm pretty sure they only have about half of the shown hashrate (it used to be two thirds, but now only half..). So you can't expect them to find a block every 6 1/3 hours.

They should still get that buggy "block found"-detection fixed. And their hashrate as well.

I have to disagree - The solution to "Block stealing by pool operators" would be to allow third party audits. The Pool software records every share found in the database it's connected to. along with the actual hash it is recorded whether bitcoind accepted that hash as a valid solution

With a bit of dedication, mining software could get the current block difficulty and check submitted shares against it also. If the submitted share solves a block, it could alert the miner very prominently that they submitted a block solve, with a full log file dump of the submitted block, and to verify the pool it was submitted to received and honors it. A pool miner could publish the block solve with proof of work. This feature would remind pool owners that miners know.

DELETE FROM shares WHERE hash = 'stolen block hash';

now audit me. ;)

well, that only works if the pool isn't showing block / share stats. Like mine does. So I guess If I was stealing from my users, and therefore deleting shares, they'd notice from the round history that shares went missing. really suspicious

As you don't have the transaction tree but only 1 single root hash from it in the header (which is all you get in the getwork request) there's no way to see where the generated transaction goes to as a miner. Even if you run bitcoind (which will become impossible in the future due to bandwidth/CPU limitations) you still can't see the most interesting transaction (the generated 50 BTC).

For audits you would only need to delete a SINGLE entry (or not record it): The hash that solved the "private" block. As the merkle root changes anyways after a block solve, it would be not detectable that in reality YOU found that block. Also you would need to log ALL transactions for every getwork to be audited if the auditor requests that, which would make log files more or less explode... and it still wouldn't be easily possible to detect whether the address that the generated amount should have gone to wasn't in the pool's wallet.

There would be only a single share missing (you could even return and mark it as stale/invalid). For the pool the round would still go on with just 1 single share out of ~1.5 million being marked invalid. It happens more often than you think that valid shares get marked invalid by a pool with no apparent reason at all, so this is nothing uncommon.

Not to make an accusation, but as I pointed out in the BitClockers thread they've had extreme bad luck for the past 25 blocks (http://forum.bitcoin.org/index.php?topic=10127.msg362367#msg362367). That's about 2 weeks worth.

Our pool bithasher.com has had really good luck :)  We are also very open on our forums and Freenode channell #bithasher
We have only been public for about a week or so and already found 3 blocks, and with 0 fees right now, all of our users receieved every bit of their portion...right down to the 8 decimal payouts :)

https://forum.bitcoin.org/index.php?topic=7737.0

*checks the SQL logs*

heeeeyyyyyy.....

Your suggestion is actually on of the things we are planning on doing on our pool bithasher.com.  We plan on having a page that lists this type of info for transparency...and also fun.  Its neat to get into compeitition with other miners on who can get highest on the "block stats" page for shares submitted, or who has the highest hashrate in the entire pool.
This is just one of the MANY changes we have coming in our pool. We also take every pool user suggestions seriously and try to work them in as soon as possible.  Check us out.

I don't think that's a fair statement to make lest anyone get the wrong idea about the integrity of bitcoins.lc; a database problem at the pool made a block solve not pay out automatically, requiring manual correction - it was still instantly posted to the round history on the site. In fact, at least one pool block solve at bitcoins.lc was invalid (another miner or pool had also solved the block but with an earlier timestamp) but Jine still paid the block out-of-pocket, without making a big deal out of it except for a casual mention in the IRC channel. I donated my share of that block back.

If a pool owner decided to steal a block's worth of BTC, you would never know about it or even have a clue, and that seems to be the issue up for discussion. If pool miner software doesn't have enough information to determine independently and report to the user that it submitted a block solve, it seems that you must trust your pool admin.