It's a real issue imo. Pool operators should have the right incentive to fix it, it's them who are going to get waterboarded until they give up the codes to change the blocks to work on.
I get that they don't want to give up the size and profits, but there are still things they could do. If you have good rep and software people will come to you and you can assign them to a subpool over which you don't have direct control, but can stop assigning people too if they suck (downtime, weird rules, etc). Subpool operators can take a slice of profit and give part to the main portal.
Oh, there is the set up where individuals set their own work. Iirc correctly that is a bulletproof system.
Topic: deepbit taking over? is there any effort to keep track of invalidated blocks? (Read 1661 times)
June 25, 2011, 08:31:14 PM
June 25, 2011, 08:19:14 PM
Big pools don't supply anything to smaller pools. No blocks, no shares.
What if a big pool registers as a miner to a small pool. It would get paid based on the shares but not provide blocks. Pool A does that with pool B 25% its size. A throws B's size at it loosing 25% speed on solving own blocks causing B to loose 50% speed but A getting paid based on shares. A would only loose 12.5% the profit and look even good as it could pay out more than based on its solved blocks would make sense.
Deepbit + slush or btcguild is already more than 50%. So the entire bitcoin economy that is oh so peer to peer independent nobody ever will control it ... depends on the good will of those behind deepbit, slush and btcguild. Isn't that a bit much trust in those 3? What is wrong in my analysis? Please enlighten me you gods of more than 100 posts!
This argument gets cast about so much. First it was deepbit and slush could conspire, now it's deepbit and/or slush and/or btcguild. It's a free market, if you don't trust them then go to a smaller pool. The pool situation will always be in a state that this argument can be made ... even if there were 5 pools that all had the same speed, how will you know that 3 of them aren't conspiring.
Actually the whole point of this thread was not about discussing details of the one pool or the other but about whether there is any mechanism to track if foul play is under way. Is there any track of invalid blocks?
June 25, 2011, 07:26:50 PM
First off, a big pool can destroy a smaller pool by providing shares but no blocks. This game played on all non-cartel pools will make it easy for a cartel to make their pools raise to gain more than 50% in combined hashing power.
Big pools don't supply anything to smaller pools. No blocks, no shares. Everyone has equal access to the block chain and gets their info from there.
Deepbit + slush or btcguild is already more than 50%. So the entire bitcoin economy that is oh so peer to peer independent nobody ever will control it ... depends on the good will of those behind deepbit, slush and btcguild. Isn't that a bit much trust in those 3? What is wrong in my analysis? Please enlighten me you gods of more than 100 posts!
This argument gets cast about so much. First it was deepbit and slush could conspire, now it's deepbit and/or slush and/or btcguild. It's a free market, if you don't trust them then go to a smaller pool. The pool situation will always be in a state that this argument can be made ... even if there were 5 pools that all had the same speed, how will you know that 3 of them aren't conspiring.
June 25, 2011, 07:13:26 PM
I'll bite. This is just too funny. And the fact that someone replied to it is hilarious.
Someone please tell me what school taught you that 3GH/9.5GH = 51%.
I really want to report them to the Department of Education of equivalent.
Someone please tell me what school taught you that 3GH/9.5GH = 51%.
I really want to report them to the Department of Education of equivalent.
First off, a big pool can destroy a smaller pool by providing shares but no blocks. This game played on all non-cartel pools will make it easy for a cartel to make their pools raise to gain more than 50% in combined hashing power.
Deepbit + slush or btcguild is already more than 50%. So the entire bitcoin economy that is oh so peer to peer independent nobody ever will control it ... depends on the good will of those behind deepbit, slush and btcguild. Isn't that a bit much trust in those 3? What is wrong in my analysis? Please enlighten me you gods of more than 100 posts!
I think his forum sig makes it even more funny. I better switch to solo mining so there's gonna be 4 peers now.
Oh guys it is not that complicated but I'll reword my sig some day so that even you will get it.
Do you realize that the peers are not the miners but the pools? The miners only do what the pool tells them to do. So according to bitcoin watch, there are seven pools accounting for 95% of the bitcoin network. That is a very bad situation. I hope to see many more pools and pool software so people just start pools with friends and communities that have a natural trust in each other beforehand.
June 25, 2011, 07:08:29 PM
Hi,
as an increase in the invalid block count would be an indicator of a 51% take over scenario and as I have seen how eligius got 4/10 blocks invalidated recently I wonder if there is any effort taken to keep track of invalidated blocks?
In my opinion the block chain should generally be a block tree containing also the invalid blocks with the client being able to request the longest chain, only. With this data the block explorer should also keep track of those lost blocks to run forensic analysis on them later.
Opinions?
as an increase in the invalid block count would be an indicator of a 51% take over scenario and as I have seen how eligius got 4/10 blocks invalidated recently I wonder if there is any effort taken to keep track of invalidated blocks?
In my opinion the block chain should generally be a block tree containing also the invalid blocks with the client being able to request the longest chain, only. With this data the block explorer should also keep track of those lost blocks to run forensic analysis on them later.
Opinions?
"eligius got 4/10 blocks invalidated recently"
Well, what about other pools?
June 25, 2011, 06:41:16 PM
I'll say it again. Ignore anyone on this forum with fewer then 100 posts.
June 25, 2011, 06:36:13 PM
I'll bite. This is just too funny. And the fact that someone replied to it is hilarious.
Someone please tell me what school taught you that 3GH/9.5GH = 51%.
I really want to report them to the Department of Education of equivalent.
Someone please tell me what school taught you that 3GH/9.5GH = 51%.
I really want to report them to the Department of Education of equivalent.
I think his forum sig makes it even more funny. I better switch to solo mining so there's gonna be 4 peers now.
June 25, 2011, 06:21:19 PM
I'll bite. This is just too funny. And the fact that someone replied to it is hilarious.
Someone please tell me what school taught you that 3GH/9.5GH = 51%.
I really want to report them to the Department of Education of equivalent.
Someone please tell me what school taught you that 3GH/9.5GH = 51%.
I really want to report them to the Department of Education of equivalent.
June 25, 2011, 06:01:53 PM
Good point. I think people are forgetting that this is a hard-coded problem in the current bitcoin beta. I can't wait for a 'full-release' version of bitcoin... I thought about investing in it but it's still beta for reasons such as this
June 25, 2011, 04:39:06 PM
Hi,
as an increase in the invalid block count would be an indicator of a 51% take over scenario and as I have seen how eligius got 4/10 blocks invalidated recently I wonder if there is any effort taken to keep track of invalidated blocks?
In my opinion the block chain should generally be a block tree containing also the invalid blocks with the client being able to request the longest chain, only. With this data the block explorer should also keep track of those lost blocks to run forensic analysis on them later.
Opinions?
as an increase in the invalid block count would be an indicator of a 51% take over scenario and as I have seen how eligius got 4/10 blocks invalidated recently I wonder if there is any effort taken to keep track of invalidated blocks?
In my opinion the block chain should generally be a block tree containing also the invalid blocks with the client being able to request the longest chain, only. With this data the block explorer should also keep track of those lost blocks to run forensic analysis on them later.
Opinions?
Jump to: