Pool Owner Keeping Generated Blocks?

[Wuked]

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.

[1714977164]

1714977164

[1714977164]

1714977164

[1714977164]

1714977164

[1714977164]

1714977164

[SgtSpike]

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?

No.

[Sukrim]

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.

[Jack of Diamonds]

Therefore, it shows up as block 136,133 on my site, because we only check for new blocks every 5 minutes or so.

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)

[Jack of Diamonds]

by the very nature of pooled mining, you
have to trust the pool operator.

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.

[Caesium]

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.

[gentakin]

Look at their solved block stats: http://www.bitcoinpool.com/index.php?do=blocks
Something seems a bit off about their round duration calculations, no?

At a speed of ~296 Gh/s they should be finding a block every 6 1/3 hours, but look at the timestamps on the blocks (not their calculated round durations, which are wrong).

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.

[antares]

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.

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

[deepceleron]

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.

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.

[gentakin]

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

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

now audit me.

[antares]

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

[Sukrim]

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.

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.

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.

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

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.

[OCedHrt]

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.

[CubedRoot]

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

[grue]

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

[enmaku]

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

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

now audit me.

*checks the SQL logs*

heeeeyyyyyy.....

[CubedRoot]

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

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.

[deepceleron]

Therefore, it shows up as block 136,133 on my site, because we only check for new blocks every 5 minutes or so.

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)

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.