bump.
Vladamir has a good thread: https://bitcointalksearch.org/topic/vladimirs-essential-self-defence-guide-for-bitcoin-miners-38785
Topic: Could BTCGuild be cheating its miners? (Read 5822 times)
The address the new coins are generated for is included in the data that's hashed and sent to miners?
Not exactly, but its hash is.Quote
So stolen blocks could be submitted anywhere in the network but they would credit the pool address that sent the block to the miners anyway.
No, stolen blocks submitted to anything but the entity that issued them are useless. You can verify that they are valid proofs of work (by confirming the hash), but you lack the information needed to submit the block to the network (because you don't have the transaction set, coinbase, and so on).It is conceivable that with diligent effort, one could perfectly re-create the block, guessing which transactions were in it and so on. But then the block would be identical and would still pay to whoever the work issuer intended it to pay.
Quote
Anyone want to confirm or deny this?
I can 100% confirm this. Otherwise, the entire bitcoin security system would fail horribly. If there was any way to change who got paid for a block after the work was completed, the proof of work would fail to prove work, its sole purpose. The whole point of the proof of work is to secure the block. 
That would take a lot of hashing power to do! And the person doing it would lose money unless it was a PPS pool.
It would be highly profitable if a found block could be used elsewhere. According to the bitcoin paper this seems possible but people on IRC were very sure it wasn't.
I'd love to know why this isn't possible. From my tcpdumps I see miners don't get the whole block to hash but surely what they do get can be predicted from the last block and the transactions to be added to it, i.e. from the data known to every up to date client. Anyone want to enlighten me?
The address the new coins are generated for is included in the data that's hashed and sent to miners?
So stolen blocks could be submitted anywhere in the network but they would credit the pool address that sent the block to the miners anyway.
Anyone want to confirm or deny this?
Confirming this. The private key to the txout address of the generation transaction is known only to the pool operator. That transaction and therefore that address is of course part of the block hash. If you changed it to one of your own, the hash would change and the block would be invalid.
Is this documented anywhere other than in the bitcoind source? The bitcoin paper seems to be pretty abstract and missing implementation details like these.
The bitcoin wiki might be of help: on this page: https://en.bitcoin.it/wiki/Block_hashing_algorithm you can see that the "merkle root" is part of the block hash. If you look on this page: https://en.bitcoin.it/wiki/Vocabulary you can see an explanation of what the Merkle root is (hash of hashes of transactions). The wiki also has a description of the bitcoin protocol.
You wont find anything about pools in the vanilla bitcoind sources. You'd have to look at pushpoold, for example, or other pool software.
Not that I think share withholding is what is happening right now, but to detect it pools could have a system where when an honest miner finds a winning share the pool could send the winning share out to all the other miners to see if they report it as the winner.
The ones that don't report it are trying to sabotage the pool and can be banned.
The ones that don't report it are trying to sabotage the pool and can be banned.
That would take a lot of hashing power to do! And the person doing it would lose money unless it was a PPS pool.
It would be highly profitable if a found block could be used elsewhere. According to the bitcoin paper this seems possible but people on IRC were very sure it wasn't.
I'd love to know why this isn't possible. From my tcpdumps I see miners don't get the whole block to hash but surely what they do get can be predicted from the last block and the transactions to be added to it, i.e. from the data known to every up to date client. Anyone want to enlighten me?
The address the new coins are generated for is included in the data that's hashed and sent to miners?
So stolen blocks could be submitted anywhere in the network but they would credit the pool address that sent the block to the miners anyway.
Anyone want to confirm or deny this?
Confirming this. The private key to the txout address of the generation transaction is known only to the pool operator. That transaction and therefore that address is of course part of the block hash. If you changed it to one of your own, the hash would change and the block would be invalid.
Is this documented anywhere other than in the bitcoind source? The bitcoin paper seems to be pretty abstract and missing implementation details like these.
Well if no mining pools have actually been cheating, this has been a great guide to get them started 
I left btcguild recently because of this. Could be a technical problem too.
yea I left it too for deepbit. I tried btcguild and it clearly wasn't giving me good numbers as the other pools and the %stale was a tad high. Considering I was only on for 3-4 hours for 2 days, that's just my opinion. I left it not looking back, Deepbit I paying 1% of stale shares really helped. Considering I had like under 5% on other pools and back around july I had around 25-70% stale numbers. I figured it was just ddos or hacking week w/e. Deepbit is dooing fine. THo I did change to PPS to stop the randomness.
That would take a lot of hashing power to do! And the person doing it would lose money unless it was a PPS pool.
It would be highly profitable if a found block could be used elsewhere. According to the bitcoin paper this seems possible but people on IRC were very sure it wasn't.
I'd love to know why this isn't possible. From my tcpdumps I see miners don't get the whole block to hash but surely what they do get can be predicted from the last block and the transactions to be added to it, i.e. from the data known to every up to date client. Anyone want to enlighten me?
The address the new coins are generated for is included in the data that's hashed and sent to miners?
So stolen blocks could be submitted anywhere in the network but they would credit the pool address that sent the block to the miners anyway.
Anyone want to confirm or deny this?
Confirming this. The private key to the txout address of the generation transaction is known only to the pool operator. That transaction and therefore that address is of course part of the block hash. If you changed it to one of your own, the hash would change and the block would be invalid.
That would take a lot of hashing power to do! And the person doing it would lose money unless it was a PPS pool.
It would be highly profitable if a found block could be used elsewhere. According to the bitcoin paper this seems possible but people on IRC were very sure it wasn't.
I'd love to know why this isn't possible. From my tcpdumps I see miners don't get the whole block to hash but surely what they do get can be predicted from the last block and the transactions to be added to it, i.e. from the data known to every up to date client. Anyone want to enlighten me?
The address the new coins are generated for is included in the data that's hashed and sent to miners?
So stolen blocks could be submitted anywhere in the network but they would credit the pool address that sent the block to the miners anyway.
Anyone want to confirm or deny this?
OR someone is trying to kill the pool by withholding shares that meet the network difficulty.
I had that theory some time ago. I was laughed at on IRC for suggesting it.
It would be stupid to withhold winning shares. A better solution would be to send work with a private generate target to 10% of the miners, and reject a winning nonce (so the client doesn't report a block found only a reject)
That would take a lot of hashing power to do! And the person doing it would lose money unless it was a PPS pool.
It would be highly profitable if a found block could be used elsewhere. According to the bitcoin paper this seems possible but people on IRC were very sure it wasn't.
I'd love to know why this isn't possible. From my tcpdumps I see miners don't get the whole block to hash but surely what they do get can be predicted from the last block and the transactions to be added to it, i.e. from the data known to every up to date client. Anyone want to enlighten me?
That would take a lot of hashing power to do! And the person doing it would lose money unless it was a PPS pool.
It could work on a small pool though.
I think the best system would be to have something like 80% of the pool as PPS and then 20% being a direct reward for finding a block.
It could work on a small pool though.
I think the best system would be to have something like 80% of the pool as PPS and then 20% being a direct reward for finding a block.
OR someone is trying to kill the pool by withholding shares that meet the network difficulty.
I had that theory some time ago. I was laughed at on IRC for suggesting it.
So now BTCGuild doesn't show what the luck is anymore it shows what the average shares are?
1,276,057/1805701 = 70.6%
Is that like -29.4% luck in the old format?
http://l0ss.net/ the 17 days that it shows on the 30 day graph looks pretty bad.
The calculations Elutheria did only went up to that 5 day streak of bad luck that there was 3 weeks ago and then included the extremely high 70% luck that followed. And averaging that all together it was something like a 10% chance that the low payout was because of chance.
I wonder what it would look like now?
1,276,057/1805701 = 70.6%
Is that like -29.4% luck in the old format?
http://l0ss.net/ the 17 days that it shows on the 30 day graph looks pretty bad.
The calculations Elutheria did only went up to that 5 day streak of bad luck that there was 3 weeks ago and then included the extremely high 70% luck that followed. And averaging that all together it was something like a 10% chance that the low payout was because of chance.
I wonder what it would look like now?
Quote
Seriously, did you even think through what you are suggesting? What is the benefit of them pulling X blocks to Pool A today, then pulling X blocks to Pool B tomorrow then putting X blocks back into Pool C the day after?
I already explained. To create large variations in luck which makes stealing -- if there is any -- much more difficult to see. And the luck on one pool can be increased above normal to make it more attractive to miners.
Well I was kicked out of #bitcoin-police for talking about this.
I told
And I was wrong about moving blocks/shares back and forth because he said that a share is only valid on the that one pool. But I'm pretty sure there are other ways of accomplishing the exact same thing like diverting hashing power from one pool to another or having one pool generate shares which are valid for the other pool so really it makes no difference.
Quote
* m0w3r ([email protected]) has joined #bitcoin-police
* ChanServ gives channel operator status to XRcode
* You have been kicked from #bitcoin-police by XRcode (please stop making false accusations)
Just. Fucking. Stop.
Quote
Seriously, did you even think through what you are suggesting? What is the benefit of them pulling X blocks to Pool A today, then pulling X blocks to Pool B tomorrow then putting X blocks back into Pool C the day after?
I already explained. To create large variations in luck which makes stealing -- if there is any -- much more difficult to see. And the luck on one pool can be increased above normal to make it more attractive to miners.
Well I was kicked out of #bitcoin-police for talking about this.
I told
He's the pool owner and he has the rights to choose a scheme he prefers, with good reason that he prefers to play it safe. If the miners doesn't like his payment scheme, they will leave.
Quote
And I was wrong about moving blocks/shares back and forth because he said that a share is only valid on the that one pool. But I'm pretty sure there are other ways of accomplishing the exact same thing like diverting hashing power from one pool to another or having one pool generate shares which are valid for the other pool so really it makes no difference.
'Pretty sure" isn't good enough to pin an accusation you know? If the block data supports your claim, I would be the first to support your accusation as well. But the fact is if you bother to log down blocks and who found them over a few thousand blocks, the data pretty much disproves your theory.
Quote
Seriously, did you even think through what you are suggesting? What is the benefit of them pulling X blocks to Pool A today, then pulling X blocks to Pool B tomorrow then putting X blocks back into Pool C the day after?
I already explained. To create large variations in luck which makes stealing -- if there is any -- much more difficult to see. And the luck on one pool can be increased above normal to make it more attractive to miners.
Well I was kicked out of #bitcoin-police for talking about this.
I told
And I was wrong about moving blocks/shares back and forth because he said that a share is only valid on the that one pool. But I'm pretty sure there are other ways of accomplishing the exact same thing like diverting hashing power from one pool to another or having one pool generate shares which are valid for the other pool so really it makes no difference.
Quote
* m0w3r ([email protected]) has joined #bitcoin-police
* ChanServ gives channel operator status to XRcode
* You have been kicked from #bitcoin-police by XRcode (please stop making false accusations)
Stealing entire blocks is a stupid way for pool operators to cheat.
It would be almost undetectable to pad their own (or a strawmans) mining stats by a small amount. I submit 1000 shares, but put into the database 1100 shares. This would give me 10% more BTC per block than I deserve.
That would suggest that BTCGuild is working with at least one other mining pool to pull this off.
Here is what I think may be happening after thinking about it for a little while. BTCGuild and some other pools, such as Deepbit, or Slush or Ars Bitcoin are actually run by the same people.
The operator of BTCGuild is intentionally manipulating the luck in the pool making it drop very low and then jump up to unexpected highs. On low luck days, they would be doing this by having the pool capture some of the winning shares and sending them over to one of the other pools where that share would be sent out to one of the miners to win. On high luck days, some of the winning shares on the other pools would be captured and sent over to BTCGuild and sent out to the miners to have them win.
During this time, some of the winning shares may be sent off to a private pool where some of the loot is kept, or are sent off to a PPS pool like Ars Bitcoin and help build up that big 800 BTC buffer that they have. Then somebody gets to keep that buffer.
But the amount of actual stealing that takes place depends on weather or not people notice. By manipulating the pool and adding positive luck, it really a great way to make most people not notice that something is wrong. So right now there is probably very little stealing actually going on but there is still a high degree of manipulation!
Here is what I think may be happening after thinking about it for a little while. BTCGuild and some other pools, such as Deepbit, or Slush or Ars Bitcoin are actually run by the same people.
The operator of BTCGuild is intentionally manipulating the luck in the pool making it drop very low and then jump up to unexpected highs. On low luck days, they would be doing this by having the pool capture some of the winning shares and sending them over to one of the other pools where that share would be sent out to one of the miners to win. On high luck days, some of the winning shares on the other pools would be captured and sent over to BTCGuild and sent out to the miners to have them win.
During this time, some of the winning shares may be sent off to a private pool where some of the loot is kept, or are sent off to a PPS pool like Ars Bitcoin and help build up that big 800 BTC buffer that they have. Then somebody gets to keep that buffer.
But the amount of actual stealing that takes place depends on weather or not people notice. By manipulating the pool and adding positive luck, it really a great way to make most people not notice that something is wrong. So right now there is probably very little stealing actually going on but there is still a high degree of manipulation!
Seriously, did you even think through what you are suggesting? What is the benefit of them pulling X blocks to Pool A today, then pulling X blocks to Pool B tomorrow then putting X blocks back into Pool C the day after?
Isn't there a simple way to find out? How about a couple of supecting miners decide to use a slightly modded miner that would inform the user when it finds a block.
It'd be sufficient for this group to be able to present only 1 block that was stolen by the operator.
Of course they would have keep their identities secret, otherwise the pool operator can just always leave their blocks untouched and choose blocks of other miners for stealing.
This would at least create a lot of danger for the pool operator. The pool operator getting caught stealing would certainly destroy the pool, so even a slight danger of that happening should keep him from stealing, right?
Am I overlooking something?
It'd be sufficient for this group to be able to present only 1 block that was stolen by the operator.
Of course they would have keep their identities secret, otherwise the pool operator can just always leave their blocks untouched and choose blocks of other miners for stealing.
This would at least create a lot of danger for the pool operator. The pool operator getting caught stealing would certainly destroy the pool, so even a slight danger of that happening should keep him from stealing, right?
Am I overlooking something?
That makes perfect sense. What I don't understand is why a mining client can't just keep the block and all 50 BTC for itself when it finds the block. Is there some protection against this happening that would also prevent a mining client from knowing when it finds a block?
Quote
From the period starting at block 137872 to 139410, initially it looked like something was fishy because BTCG found less blocks than Slush despite having higher hashrate, but over the period, this slowly corrected and BTCG found more blocks than Slush, with Slush performing below par (all the top pools were getting about 5.5~6.5 BTC per GH/s while Slush was just below 5). So I figured there probably was nothing fishy going on but merely that the run of bad luck got everybody paranoid and left it at that.
That would suggest that BTCGuild is working with at least one other mining pool to pull this off.
Here is what I think may be happening after thinking about it for a little while. BTCGuild and some other pools, such as Deepbit, or Slush or Ars Bitcoin are actually run by the same people.
The operator of BTCGuild is intentionally manipulating the luck in the pool making it drop very low and then jump up to unexpected highs. On low luck days, they would be doing this by having the pool capture some of the winning shares and sending them over to one of the other pools where that share would be sent out to one of the miners to win. On high luck days, some of the winning shares on the other pools would be captured and sent over to BTCGuild and sent out to the miners to have them win.
During this time, some of the winning shares may be sent off to a private pool where some of the loot is kept, or are sent off to a PPS pool like Ars Bitcoin and help build up that big 800 BTC buffer that they have. Then somebody gets to keep that buffer.
But the amount of actual stealing that takes place depends on weather or not people notice. By manipulating the pool and adding positive luck, it really a great way to make most people not notice that something is wrong. So right now there is probably very little stealing actually going on but there is still a high degree of manipulation!
Why?
My god, you are a fucking idiot...
Jump to: