eleuthria (OP)
Legendary
Offline
Activity: 1750
Merit: 1007
|
|
January 06, 2014, 04:29:13 AM Last edit: January 06, 2014, 05:16:06 AM by eleuthria |
|
I'm glad other people can spot when the pool isn't doing it's job. If no one caught onto this, would this just be buried by time? I guess I'm glad I don't understand the hard technical stuff, cause I'd be looking for holes all the time and would probably be spotting them all the time. I guess it's like taking money from a blind person. Who monitors the monitor? Not doing it's job, but not working %100 I guess. It's extremely rare since all of the bitcoind's on the various pool servers are connected to the payment server, so the odds of the payment server seeing a competing block before a Guild block are *very* low (less than 1 in 10 orphans). When they are missed, it's generally corrected a few hours later manually without anybody noticing, but it does take a few hours because correcting it is a manual process, including the detection that it happened in the first place. Bitcoind does not report orphaned blocks via any RPC commands if they were not originally accepted. The current project for the pool is a complete ground-up rewrite of the Stratum code to make it more scalable (full utilization of many-core systems), allow for better merged mining integration (instead of the fairly limited version currently implemented), and multiple chains (for an scrypt multipool). Part of this rewrite is also going to make the pool servers insert found blocks directly to the database, and then the payout server will check against them before awards are assigned. It won't prevent them from still needing manual intervention to get them paid (as a security/sanity check), but it will make sure they're properly logged at the time they're found and identified as not yet paid out in the Pool Stats page.
|
RIP BTC Guild, April 2011 - June 2015
|
|
|
sbfree
|
|
January 06, 2014, 04:55:14 AM |
|
I'm glad other people can spot when the pool isn't doing it's job. If no one caught onto this, would this just be buried by time? I guess I'm glad I don't understand the hard technical stuff, cause I'd be looking for holes all the time and would probably be spotting them all the time. I guess it's like taking money from a blind person. Who monitors the monitor? Not doing it's job, but not working %100 I guess. It's extremely rare since all of the bitcoind's on the various pool servers are connected to the payment server, so the odds of the payment server seeing a competing block before a Guild block are *very* low (less than 1 in 10 orphans). When they are missed, it's generally corrected a few hours later manually without anybody noticing, but it does take a few hours because correcting it is a manual process. Bitcoind does not report orphaned blocks via any RPC commands if they were not originally accepted. The current project for the pool is a complete ground-up rewrite of the Stratum code to make it more scalable (full utilization of many-core systems), allow for better merged mining integration (instead of the fairly limited version currently implemented), and multiple chains (for an scrypt multipool). Part of this rewrite is also going to make the pool servers insert found blocks directly to the database, and then the payout server will check against them before awards are assigned. It won't prevent them from still needing manual intervention to get them paid (as a security/sanity check), but it will make sure they're properly logged at the time they're found and identified as not yet paid out in the Pool Stats page. yeah! ... what eleuthria says get'em @el
|
|
|
|
guytechie
|
|
January 06, 2014, 12:06:16 PM |
|
Wow, we're at 3120 TH now. That was quick...
|
Put something in my tip jar if I made your day. BTC: 1MkmBHDjonAFXui6JEx9ZmEemfMtUo9Cmu
|
|
|
AussieHash
|
|
January 06, 2014, 12:42:43 PM |
|
Wow, we're at 3120 TH now. That was quick...
I know, 2-3 days ago i had 3.5 million shares per shift, now down to 2.8million
|
|
|
|
CYPER
|
|
January 06, 2014, 12:55:57 PM |
|
No, I wish to stand outside the restaurant saying that the restaurant and the food are good in general, but can be improved. What is so bad with adding luck per user selectable length of time to the already good selection of statistics? How is that against the interest of pool users? Wouldn't you like it if you could see what the luck was for the past 7 days for example?
I've said this before, but I'll repeat myself. Why does it matter? Luck is luck. Sometimes it's good, sometimes it's bad. You have no control over it. If you're considering going to a pool because it has "good luck", make sure you throw salt over your shoulder first. M If it doesn't matter then why every single major pool including BTCGuild display luck? You are making a point that luck does not matter, yet the reality shows it does: people use it to feel good about their choices, regardless of being completely random. GHash.io doesn't have and luck stats. Ghash.io have a total proofs of work per block data, from where a 6 years old could easily check luck. Who monitors the monitor? Realistically a pool admin can always do shady things behind the curtains, so that is why it is important to have transparency in order to sustain trust in its user base by giving them the power to check/verify. When an admin refuses to publish specific data, that doesn't speak very well for the transparency of his service. There is a saying that goes: if you want something you will find a way, if you don't then you will find an excuse.
|
|
|
|
opentoe
Legendary
Offline
Activity: 1274
Merit: 1000
Personal text my ass....
|
|
January 06, 2014, 08:11:52 PM |
|
I'm glad other people can spot when the pool isn't doing it's job. If no one caught onto this, would this just be buried by time? I guess I'm glad I don't understand the hard technical stuff, cause I'd be looking for holes all the time and would probably be spotting them all the time. I guess it's like taking money from a blind person. Who monitors the monitor? Not doing it's job, but not working %100 I guess. It's extremely rare since all of the bitcoind's on the various pool servers are connected to the payment server, so the odds of the payment server seeing a competing block before a Guild block are *very* low (less than 1 in 10 orphans). When they are missed, it's generally corrected a few hours later manually without anybody noticing, but it does take a few hours because correcting it is a manual process, including the detection that it happened in the first place. Bitcoind does not report orphaned blocks via any RPC commands if they were not originally accepted. The current project for the pool is a complete ground-up rewrite of the Stratum code to make it more scalable (full utilization of many-core systems), allow for better merged mining integration (instead of the fairly limited version currently implemented), and multiple chains (for an scrypt multipool). Part of this rewrite is also going to make the pool servers insert found blocks directly to the database, and then the payout server will check against them before awards are assigned. It won't prevent them from still needing manual intervention to get them paid (as a security/sanity check), but it will make sure they're properly logged at the time they're found and identified as not yet paid out in the Pool Stats page. Can't you just program an exception report and post that? I'm sure you are human and maybe have missed some yourself, no?
|
|
|
|
|
eleuthria (OP)
Legendary
Offline
Activity: 1750
Merit: 1007
|
|
January 06, 2014, 11:27:12 PM |
|
The block you just linked is from ghash.io EDIT: NVM, under it is the BTC Guild orphan. That orphan is shown out of order (it's the one posted about on another page). It's between 278780 and 278783. Like I said, since that orphan was never seen by the payout server so it had to be manually forced in.
|
RIP BTC Guild, April 2011 - June 2015
|
|
|
|
eleuthria (OP)
Legendary
Offline
Activity: 1750
Merit: 1007
|
|
January 07, 2014, 12:15:23 AM |
|
Looks like that's an orphan. It won't get marked as one by BTC Guild until it finds another block (blocks are marked as "Orphan" once the pool finds another block and sees that the previous block does not have at least 2 confirmations). It really sucks that ghash.io has become the dominant pool, yet has by far the worst connectivity with the entire network of any other pool, leading to significantly higher orphan rates across the board, both for them and for other pools.
|
RIP BTC Guild, April 2011 - June 2015
|
|
|
guytechie
|
|
January 07, 2014, 12:57:15 AM Last edit: January 07, 2014, 01:10:38 AM by guytechie |
|
Wow, we're at 3120 TH now. That was quick...
I know, 2-3 days ago i had 3.5 million shares per shift, now down to 2.8million 3225 TH/s! 105 TH in just over 12 hrs!
|
Put something in my tip jar if I made your day. BTC: 1MkmBHDjonAFXui6JEx9ZmEemfMtUo9Cmu
|
|
|
AussieHash
|
|
January 07, 2014, 01:22:40 AM Last edit: January 07, 2014, 01:58:12 AM by AussieHash |
|
Looks like that's an orphan. It won't get marked as one by BTC Guild until it finds another block (blocks are marked as "Orphan" once the pool finds another block and sees that the previous block does not have at least 2 confirmations). It really sucks that ghash.io has become the dominant pool, yet has by far the worst connectivity with the entire network of any other pool, leading to significantly higher orphan rates across the board, both for them and for other pools.
Conspiracy theories about selfish and evil pools aside, I wonder if this hurts them more or harms them. It would probably harm other pools which pay for orphans and PPS Vitalik writes about a "12 second propagation time" in this article http://bitcoinmagazine.com/8972/quarkcoin-noble-intentions-wrong-approach/If ghash's blocks take longer than 12 seconds to propogate, then all other miners are wasting time hashing the old block. As ghash have less than 51% of the network there would be a significant risk of another miner producing a competing valid block, but with 40% of the network, ghash would still have a high chance of multiple sequential blocks (6 in a row today) and lengthening their own chain Edit <conspiracy theory> : if ghash maintained 40% share, if they were responsible for increasing the entire network's orphan rate slightly (even 0.5%) would that slowly kill off all other pools profit margin (and drive more miners to them)?</tin foil>
|
|
|
|
eleuthria (OP)
Legendary
Offline
Activity: 1750
Merit: 1007
|
|
January 07, 2014, 02:06:50 AM |
|
Looks like that's an orphan. It won't get marked as one by BTC Guild until it finds another block (blocks are marked as "Orphan" once the pool finds another block and sees that the previous block does not have at least 2 confirmations). It really sucks that ghash.io has become the dominant pool, yet has by far the worst connectivity with the entire network of any other pool, leading to significantly higher orphan rates across the board, both for them and for other pools.
Conspiracy theories about selfish and evil pools aside, I wonder if this hurts them more or harms them. It would probably harm other pools which pay for orphans and PPS Vitalik writes about a "12 second propagation time" in this article http://bitcoinmagazine.com/8972/quarkcoin-noble-intentions-wrong-approach/If ghash's blocks take longer than 12 seconds to propogate, then all other miners are wasting time hashing the old block. As ghash have less than 51% of the network there would be a significant risk of another miner producing a competing valid block, but with 40% of the network, ghash would still have a high chance of multiple sequential blocks (6 in a row today) and lengthening their own chain Edit <conspiracy theory> : if ghash maintained 40% share, if they were responsible for increasing the entire network's orphan rate slightly (even 0.5%) would that slowly kill off all other pools profit margin (and drive more miners to them)?</tin foil> The 12 second time is more for full-network propagation. Pool-to-pool communications *should* be significantly faster if they're well connected like *most* pools are. The vast majorities of pools are just a few hops away and have the bandwidth to push/receive blocks in miliseconds unlike home connections which are likely taking 1-3 seconds to relay a 1MB block to each of their peers.
|
RIP BTC Guild, April 2011 - June 2015
|
|
|
mdude77
Legendary
Offline
Activity: 1540
Merit: 1001
|
|
January 07, 2014, 02:19:02 AM |
|
I just got my first cube up and running. It looks like it's working, going through my stratum proxy. But my worker is showing zero hashrate? I'm pointing to the backup server. Is there a delay in hashrates being counted, or am I doing something wrong?
M
|
I mine at Kano's Pool because it pays the best and is completely transparent! Come join me!
|
|
|
eleuthria (OP)
Legendary
Offline
Activity: 1750
Merit: 1007
|
|
January 07, 2014, 02:26:20 AM |
|
I just got my first cube up and running. It looks like it's working, going through my stratum proxy. But my worker is showing zero hashrate? I'm pointing to the backup server. Is there a delay in hashrates being counted, or am I doing something wrong?
M
Sure you got the right worker credentials? Hash rates update after a minute or so. Shares show up within 10 seconds.
|
RIP BTC Guild, April 2011 - June 2015
|
|
|
mdude77
Legendary
Offline
Activity: 1540
Merit: 1001
|
|
January 07, 2014, 02:42:24 AM Last edit: January 07, 2014, 02:57:00 AM by mdude77 |
|
I just got my first cube up and running. It looks like it's working, going through my stratum proxy. But my worker is showing zero hashrate? I'm pointing to the backup server. Is there a delay in hashrates being counted, or am I doing something wrong?
M
Sure you got the right worker credentials? Hash rates update after a minute or so. Shares show up within 10 seconds. EDIT: looks like cubes don't like the "no midstate" option with slush's proxy. M
|
I mine at Kano's Pool because it pays the best and is completely transparent! Come join me!
|
|
|
curt.rowland
Member
Offline
Activity: 77
Merit: 10
|
|
January 07, 2014, 02:45:18 AM |
|
Hello all, I am still new at this and really new here. I was wondering what advantages there are for joining a team? Should I join a team or will my rewards be just the same either way?
|
|
|
|
Trongersoll
|
|
January 07, 2014, 03:14:33 AM |
|
Hello all, I am still new at this and really new here. I was wondering what advantages there are for joining a team? Should I join a team or will my rewards be just the same either way?
Teams offer no advantage.
|
|
|
|
eleuthria (OP)
Legendary
Offline
Activity: 1750
Merit: 1007
|
|
January 07, 2014, 03:22:39 AM |
|
Hello all, I am still new at this and really new here. I was wondering what advantages there are for joining a team? Should I join a team or will my rewards be just the same either way?
Teams are a "for fun" feature. They offer no changes to rewards in any way. They're designed as a way for users to either compete with a smaller subset of users in rankings (some people like competition even if it's just a numbers game), or group up with friends to compete against another group.
|
RIP BTC Guild, April 2011 - June 2015
|
|
|
mdude77
Legendary
Offline
Activity: 1540
Merit: 1001
|
|
January 07, 2014, 03:29:35 AM Last edit: January 07, 2014, 01:10:58 PM by mdude77 |
|
I just got my first cube up and running. It looks like it's working, going through my stratum proxy. But my worker is showing zero hashrate? I'm pointing to the backup server. Is there a delay in hashrates being counted, or am I doing something wrong?
M
Sure you got the right worker credentials? Hash rates update after a minute or so. Shares show up within 10 seconds. EDIT: looks like cubes don't like the "no midstate" option with slush's proxy. M Using bfgminer as a proxy is so much easier. Once you realize only the 32-bit version has the proxy. M EDIT: bfgminer is easier, but it doesn't do as well. Cruising at almost 39gh/s thru slush's proxy, couldn't top 35 thru bfg.
|
I mine at Kano's Pool because it pays the best and is completely transparent! Come join me!
|
|
|
|