Bitcoin Forum
November 06, 2024, 07:28:01 AM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 [2]  All
  Print  
Author Topic: Pool Owner Keeping Generated Blocks?  (Read 4074 times)
Wuked
Member
**
Offline Offline

Activity: 112
Merit: 10


View Profile WWW
July 13, 2011, 11:30:10 PM
 #21

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.

SgtSpike
Legendary
*
Offline Offline

Activity: 1400
Merit: 1005



View Profile
July 14, 2011, 12:16:43 AM
 #22

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
Legendary
*
Offline Offline

Activity: 2618
Merit: 1007


View Profile
July 14, 2011, 12:33:50 AM
 #23

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.

https://www.coinlend.org <-- automated lending at various exchanges.
https://www.bitfinex.com <-- Trade BTC for other currencies and vice versa.
Jack of Diamonds
Sr. Member
****
Offline Offline

Activity: 252
Merit: 251



View Profile
July 14, 2011, 07:32:21 AM
 #24

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)

1f3gHNoBodYw1LLs3ndY0UanYB1tC0lnsBec4USeYoU9AREaCH34PBeGgAR67fx
Jack of Diamonds
Sr. Member
****
Offline Offline

Activity: 252
Merit: 251



View Profile
July 14, 2011, 08:02:44 AM
Last edit: July 14, 2011, 10:13:33 AM by Jack of Diamonds
 #25

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.

1f3gHNoBodYw1LLs3ndY0UanYB1tC0lnsBec4USeYoU9AREaCH34PBeGgAR67fx
Caesium
Hero Member
*****
Offline Offline

Activity: 546
Merit: 500


View Profile
July 14, 2011, 10:11:37 AM
 #26

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.

Tired of annoying signature ads? Ad block for signatures
gentakin
Member
**
Offline Offline

Activity: 98
Merit: 10


View Profile
July 14, 2011, 12:30:18 PM
 #27

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.

1HNjbHnpu7S3UUNMF6J9yWTD597LgtUCxb
antares
Hero Member
*****
Offline Offline

Activity: 518
Merit: 500


View Profile
July 14, 2011, 01:36:18 PM
 #28

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
Legendary
*
Offline Offline

Activity: 1512
Merit: 1036



View Profile WWW
July 14, 2011, 01:38:56 PM
 #29

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
Member
**
Offline Offline

Activity: 98
Merit: 10


View Profile
July 14, 2011, 02:14:29 PM
 #30

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

1HNjbHnpu7S3UUNMF6J9yWTD597LgtUCxb
antares
Hero Member
*****
Offline Offline

Activity: 518
Merit: 500


View Profile
July 14, 2011, 02:41:51 PM
 #31

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
Legendary
*
Offline Offline

Activity: 2618
Merit: 1007


View Profile
July 14, 2011, 02:45:43 PM
 #32

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.

https://www.coinlend.org <-- automated lending at various exchanges.
https://www.bitfinex.com <-- Trade BTC for other currencies and vice versa.
OCedHrt
Member
**
Offline Offline

Activity: 111
Merit: 10


View Profile
July 14, 2011, 04:52:47 PM
 #33

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.

ALL.ME  ●●●  SOCIAL NETWORK OF THE BLOCKCHAIN TIME ●●●
▄▄▄▬▬▄▄▄  Bounty all.me ▶ Jan 29th - May 8th 2018  ▄▄▄▬▬▄▄▄
Facebook   ▲   Twitter   ▲   Telegram
CubedRoot
Sr. Member
****
Offline Offline

Activity: 291
Merit: 250


View Profile
July 14, 2011, 11:13:07 PM
 #34

Our pool bithasher.com has had really good luck Smiley  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 Smiley
grue
Legendary
*
Offline Offline

Activity: 2058
Merit: 1446



View Profile
July 14, 2011, 11:13:15 PM
 #35

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

It is pitch black. You are likely to be eaten by a grue.

Adblock for annoying signature ads | Enhanced Merit UI
enmaku
Hero Member
*****
Offline Offline

Activity: 742
Merit: 500


View Profile
July 14, 2011, 11:16:28 PM
 #36

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

*checks the SQL logs*

heeeeyyyyyy.....
CubedRoot
Sr. Member
****
Offline Offline

Activity: 291
Merit: 250


View Profile
July 15, 2011, 12:06:30 AM
 #37

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
Legendary
*
Offline Offline

Activity: 1512
Merit: 1036



View Profile WWW
July 15, 2011, 01:49:58 AM
 #38

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.
Pages: « 1 [2]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!