eleuthria
Legendary
Offline
Activity: 1750
Merit: 1007
|
 |
December 19, 2013, 06:24:40 AM |
|
How can ghash.io negatively influence another pool's orphan rate? I can see how being well connected can reduce their own orphan rate, but how can they increase someone else's orphan rate?
Most pools are in at least decent datacenters, which happens to mean they have low latencies with the other pools since they're both close to backbone bandwidth providers. This reduces overall network orphan rate because the average time between block notifications between the majority of the network hash rate is significantly lower than what it would be between people just running on random local ISPs. At the same time, GHash.io has abysmal latency and/or absolutely no peers setup between pools, or they're purposely ignoring competing blocks sometimes based on the sheer number of orphan races they compete in. This is based on admittedly more casual observation rather than deep analysis, but I know other pool ops have been seeing more losing orphan races than usual as a result of ghash.io. So you mean that GHash.IO are could be causing more orphan races than usual, rather than winning more orphan races than usual? Or both? Am I right in assuming that this is only an issue because they have such a large chunk of the pie? I'll do an exact count later. They are not winning more orphan races than usual given their hash rate. But for the most part, the seem to more often than not lose an orphan race to anybody else if they didn't solve the next block themselves (because rarely is their block the first seen by the rest of the network when they're in a race), and they definitely are participating in an unusually large number of orphan races for being ~30% of the network.
|
RIP BTC Guild, April 2011 - June 2015
|
|
|
gourmet
|
 |
December 19, 2013, 08:04:33 AM |
|
If it was orphaned, why did I just get BTC from it??? Will they take that back? You haven't got confirmed BTC from it. It will be deducted from the total as soon as it is flagged as Invalid. Rather galling, considering that our result was timed first (by one second). Both block Timestamp and Time received on Blockchain.info is one second earlier for us... It's a bit strange that somebody can influence the validity of our block later... It looks like a "xx % attack" (not literally, of course, but it works that way, even when xx < 50 %). When somebody ignores a block and builds on a newer one, that is his one... With enough power, it can make some gain.
|
|
|
|
KNK
|
 |
December 19, 2013, 08:44:29 AM |
|
And another one - 275792This time ours is 15 sec earlier, but GHash.IO found two in a row in less than a minute.
|
|
|
|
KNK
|
 |
December 19, 2013, 09:20:02 AM |
|
Hopefully ghash.io is not testing out the selfish mining strategy...
I'm more inclined to say incompetence over malice. I honestly think they don't have the slightest clue what they're doing when it comes to setting up a pool and bitcoind node, as demonstrated by their almost daily outages of either their public pool or private mining side (or both). On my opinion the problem is that most of their hashing power is in locations with low cost electricity and space, which is usually in locations with bad connectivity (at the end of the world and a bit further). Because of that each datacenter is working on it's own mostly, with just few outside connections to synchronize with the network. So you mean that GHash.IO are could be causing more orphan races than usual, rather than winning more orphan races than usual? Or both?
Am I right in assuming that this is only an issue because they have such a large chunk of the pie?
I think it's both (causing and winning), because of large chunk separated from badly connected to the network. It was similar when ASICminer had a big chunk in a single location with good connectivity - GHash.IO have it in few with bad connectivity, so the problem appeared a bit earlier. There should be no single entity with much power (no more than 25%), but there is also another reason causing the big number of orphans - the rate is 9.63 blocks per hour, which is also 30+% over the normal rate for the network. Once it drops below 20% the things will normalize.
|
|
|
|
organofcorti
Donator
Legendary
Offline
Activity: 2058
Merit: 1007
Poor impulse control.
|
 |
December 19, 2013, 10:32:16 AM |
|
So you mean that GHash.IO are could be causing more orphan races than usual, rather than winning more orphan races than usual? Or both?
Am I right in assuming that this is only an issue because they have such a large chunk of the pie?
I think it's both (causing and winning), because of large chunk separated from badly connected to the network. It was similar when ASICminer had a big chunk in a single location with good connectivity - GHash.IO have it in few with bad connectivity, so the problem appeared a bit earlier. There should be no single entity with much power (no more than 25%), but there is also another reason causing the big number of orphans - the rate is 9.63 blocks per hour, which is also 30+% over the normal rate for the network. Once it drops below 20% the things will normalize. I'm not quite following you there - BTCGuild has had well over 30% of the hashrate at times and has not caused similar issues.
|
|
|
|
phrozenspite
|
 |
December 19, 2013, 12:10:41 PM |
|
hey slush or another admin can you check the helpdesk for the site?
|
|
|
|
Sir Alan
|
 |
December 19, 2013, 12:36:07 PM |
|
And another one - 275792This time ours is 15 sec earlier, but GHash.IO found two in a row in less than a minute. “Mr Bond, they have a saying in Chicago: 'Once is happenstance. Twice is coincidence. The third time it's enemy action'.”
|
1Eeyore17YeHrbJW5Q3pSdV8sXujkdrrFc
|
|
|
AlexeyK
|
 |
December 19, 2013, 01:49:44 PM |
|
congrats pool with 0.5 petahash
|
if you think that i deserve it 185h9KXxW2Efx6ynFM61ydUKsRNaVWUobs or GLC - GQjVzfk3k8gb3Cy65mBUf4ADkNNTRHgsx8
|
|
|
KNK
|
 |
December 19, 2013, 03:42:40 PM |
|
I'm not quite following you there - BTCGuild has had well over 30% of the hashrate at times and has not caused similar issues.
I was conservative with the 25% figure and it was not based on some calculations (yes, you can say it's out of thin air), but ... There are hundreds of thousands peers on the network and each client connects to up to 8 or 16 peers, some are connected to more (accepting inbound connections and no nat), but still there are several hops required to connect all. Lets say Pool A has huge chunk of the hashing power, but is well connected to other (100+) peers and some pools - those pools won't have problems. A solo miner may still produce an orphan block if not well connected, which is his own problem and will rarely happen, but ... There is a Pool B with similar (good) connectivity and also large chunk of the hashspeed, which does not have direct connection to Pool A or any of it's peers, but to some other set of pools - the end result is an increased chance for the network to be split and with that comes an increased chance for orphan blocks from both sides. If the block generation rate is slow normal - 10min are enough for the blocks to pass from Pool A to Pool B, but for short blocks (like it is now) the chance for orphans increases. Right now the situation is exactly that - GHash.IO is separated from the rest of the pools, which are well connected via the same backbone providers and has a large chunk of the power, but at the same time is connected to enough peers to propagate their work to the network. I hope this explanation is more clear what i meant.
|
|
|
|
bspurloc
|
 |
December 20, 2013, 10:29:34 PM |
|
is the slush mining proxy flakey? Got my blades going 10+gh/s now. had 2 pointed at a bfg proxy and 1 pointed at slush's mining proxy. The one pointed at his proxy reported for the last 8 hours 10.9gh/s while slush pool reported the blade was only doing 9.6gh/s. That is too much of a different to be luck etc... I then pointed that blade at a bfg proxy, I did not reboot the blade. I simply stopped the slush miner and made bfg take over at that IP/port. It immediately started to rise above 9.6gh/s on the pool and was at 10.6 on the next block as it delcared it was doing. All the same network, same pc, same everything, so it 100% was the slush mining proxy skimming 1gh/s off.
|
|
|
|
organofcorti
Donator
Legendary
Offline
Activity: 2058
Merit: 1007
Poor impulse control.
|
 |
December 20, 2013, 11:01:16 PM |
|
I hope this explanation is more clear what i meant.
Thanks for the clarification.
|
|
|
|
BuhTuglia
|
 |
December 20, 2013, 11:52:02 PM |
|
Who's getting all the blocks now? Private pools, or tera-hashing solo miners? I know it ain't us.
|
Just another dust miner... Enquiring Gnomes want to Mine! Send nothing to 16SVa2iQA6HuNPDGYShpmeEvUBRi2gW7f1
|
|
|
laureen
Newbie
Offline
Activity: 8
Merit: 0
|
 |
December 21, 2013, 12:40:23 AM |
|
Who's getting all the blocks now? Private pools, or tera-hashing solo miners? I know it ain't us.
sorry for the dumb question - i'm still learning - but are you asking this because your miner also stopped to work as mine? when i restart bfgminer, it tells me: [2013-12-21 01:29:45] Probing for an alive pool [2013-12-21 01:29:46] Pool 0 stratum+tcp://stratum.bitcoin.cz:3333 alive [2013-12-21 01:29:46] Network difficulty changed to 908M ( 6.50Ph/s) [2013-12-21 01:29:46] Stratum from pool 0 detected new block [2013-12-21 01:29:46] Pool 0 is hiding block contents from us [2013-12-21 01:29:54] Stratum from pool 0 requested work update [2013-12-21 01:30:23] Stratum from pool 0 requested work update [2013-12-21 01:30:24] Stratum from pool 0 requested work update ...
Would someone be so kind to describe what "Pool 0 is hiding block contents from us" means? Thank you in advance!
|
|
|
|
BuhTuglia
|
 |
December 21, 2013, 01:42:50 AM |
|
Who's getting all the blocks now? Private pools, or tera-hashing solo miners? I know it ain't us.
sorry for the dumb question - i'm still learning - but are you asking this because your miner also stopped to work as mine? when i restart bfgminer, it tells me: [2013-12-21 01:29:45] Probing for an alive pool [2013-12-21 01:29:46] Pool 0 stratum+tcp://stratum.bitcoin.cz:3333 alive [2013-12-21 01:29:46] Network difficulty changed to 908M ( 6.50Ph/s) [2013-12-21 01:29:46] Stratum from pool 0 detected new block [2013-12-21 01:29:46] Pool 0 is hiding block contents from us [2013-12-21 01:29:54] Stratum from pool 0 requested work update [2013-12-21 01:30:23] Stratum from pool 0 requested work update [2013-12-21 01:30:24] Stratum from pool 0 requested work update ...
Would someone be so kind to describe what "Pool 0 is hiding block contents from us" means? Thank you in advance! My BJGminer says that all the time too, and continues to work normally, so I just ignore it. Yes, I'd be curious to know what it means too. I'm sure it's been explained on here many times, but I can't find it. russell
|
Just another dust miner... Enquiring Gnomes want to Mine! Send nothing to 16SVa2iQA6HuNPDGYShpmeEvUBRi2gW7f1
|
|
|
eleuthria
Legendary
Offline
Activity: 1750
Merit: 1007
|
 |
December 21, 2013, 02:18:39 AM |
|
Who's getting all the blocks now? Private pools, or tera-hashing solo miners? I know it ain't us.
sorry for the dumb question - i'm still learning - but are you asking this because your miner also stopped to work as mine? when i restart bfgminer, it tells me: [2013-12-21 01:29:45] Probing for an alive pool [2013-12-21 01:29:46] Pool 0 stratum+tcp://stratum.bitcoin.cz:3333 alive [2013-12-21 01:29:46] Network difficulty changed to 908M ( 6.50Ph/s) [2013-12-21 01:29:46] Stratum from pool 0 detected new block [2013-12-21 01:29:46] Pool 0 is hiding block contents from us [2013-12-21 01:29:54] Stratum from pool 0 requested work update [2013-12-21 01:30:23] Stratum from pool 0 requested work update [2013-12-21 01:30:24] Stratum from pool 0 requested work update ...
Would someone be so kind to describe what "Pool 0 is hiding block contents from us" means? Thank you in advance! My BJGminer says that all the time too, and continues to work normally, so I just ignore it. Yes, I'd be curious to know what it means too. I'm sure it's been explained on here many times, but I can't find it. russell Hiding block contents just means the pool doesn't let you request the full raw block of data. AFAIK none of the stratum pools have this enabled at the moment. bfgminer complains about that. Transparency would be nice, but it's at the cost of massive bandwidth requirements (raw block contents can be 300-500 KB or more), creating an easy way for malicious users to cause massive bills/exhaust available connection bandwidth.
|
RIP BTC Guild, April 2011 - June 2015
|
|
|
BuhTuglia
|
 |
December 21, 2013, 02:25:32 AM |
|
Who's getting all the blocks now? Private pools, or tera-hashing solo miners? I know it ain't us.
sorry for the dumb question - i'm still learning - but are you asking this because your miner also stopped to work as mine? when i restart bfgminer, it tells me: [2013-12-21 01:29:45] Probing for an alive pool [2013-12-21 01:29:46] Pool 0 stratum+tcp://stratum.bitcoin.cz:3333 alive [2013-12-21 01:29:46] Network difficulty changed to 908M ( 6.50Ph/s) [2013-12-21 01:29:46] Stratum from pool 0 detected new block [2013-12-21 01:29:46] Pool 0 is hiding block contents from us [2013-12-21 01:29:54] Stratum from pool 0 requested work update [2013-12-21 01:30:23] Stratum from pool 0 requested work update [2013-12-21 01:30:24] Stratum from pool 0 requested work update ...
Would someone be so kind to describe what "Pool 0 is hiding block contents from us" means? Thank you in advance! My BJGminer says that all the time too, and continues to work normally, so I just ignore it. Yes, I'd be curious to know what it means too. I'm sure it's been explained on here many times, but I can't find it. russell Hiding block contents just means the pool doesn't let you request the full raw block of data. AFAIK none of the stratum pools have this enabled at the moment. bfgminer complains about that. Transparency would be nice, but it's at the cost of massive bandwidth requirements (raw block contents can be 300-500 KB or more), creating an easy way for malicious users to cause massive bills/exhaust available connection bandwidth. I see... thanks for the info... very interesting, and sensible. russell
|
Just another dust miner... Enquiring Gnomes want to Mine! Send nothing to 16SVa2iQA6HuNPDGYShpmeEvUBRi2gW7f1
|
|
|
dbell
Newbie
Offline
Activity: 59
Merit: 0
|
 |
December 21, 2013, 02:55:47 AM |
|
I have a some older technology Getwork miners working through a Stratum Proxy hashing on Slush. Running around 50 to 70 GH combined
I had one recent round, 21228, where I had no reward for any shares. What is up? The value formula indicates the reward should have been 0.0013 BTC. "The reward earned by a given user is given by the following formula: (25 BTC + block fees - 2% fee) * (shares found by user's workers) / (total shares in current round)"
Not much loss but it seems like something is wrong or I don't understand the BTC reward algorithm, or I don't undestand reward reporting.
Round Duration Total Shares My Shares BTC Reward Block # Block Value Validation 21230 1:43:31 728080133 102720 0.00390706 276139 25.04945416 98 confirmations left 21229 9:39:26 4091124633 480476 0.00383220 276127 25.12559563 86 confirmations left 21228 4:35:30 1928606238 102602 0.00000000 276067 25.17414052 26 confirmations left 21227 0:46:16 323420163 47502 0.00321315 276036 25.06559435 confirmed 21226 0:14:56 104058374 13282 0.00321300 276031 25.01980000 confirmed 21225 1:07:44 472925199 64496 0.00285957 276029 25.20153852 confirmed 21224 0:04:17 29652709 4292 0.00351801 276018 25.03507003 confirmed 21223 1:52:10 783569002 58652 0.00273363 276016 25.05123438 confirmed
Round 21224 sure was a winner!
|
|
|
|
FiniteMatter
Newbie
Offline
Activity: 21
Merit: 0
|
 |
December 21, 2013, 07:04:59 AM |
|
I have a some older technology Getwork miners working through a Stratum Proxy hashing on Slush. Running around 50 to 70 GH combined
I had one recent round, 21228, where I had no reward for any shares. What is up? The value formula indicates the reward should have been 0.0013 BTC. "The reward earned by a given user is given by the following formula: (25 BTC + block fees - 2% fee) * (shares found by user's workers) / (total shares in current round)"
Not much loss but it seems like something is wrong or I don't understand the BTC reward algorithm, or I don't undestand reward reporting.
Round Duration Total Shares My Shares BTC Reward Block # Block Value Validation 21230 1:43:31 728080133 102720 0.00390706 276139 25.04945416 98 confirmations left 21229 9:39:26 4091124633 480476 0.00383220 276127 25.12559563 86 confirmations left 21228 4:35:30 1928606238 102602 0.00000000 276067 25.17414052 26 confirmations left 21227 0:46:16 323420163 47502 0.00321315 276036 25.06559435 confirmed 21226 0:14:56 104058374 13282 0.00321300 276031 25.01980000 confirmed 21225 1:07:44 472925199 64496 0.00285957 276029 25.20153852 confirmed 21224 0:04:17 29652709 4292 0.00351801 276018 25.03507003 confirmed 21223 1:52:10 783569002 58652 0.00273363 276016 25.05123438 confirmed
Round 21224 sure was a winner!
I've had the all zeros thing happen to me before too, but I found out that my miners weren't connected during that time because of an issue on my stratum proxy (nat'ing issue) so they weren't able to connect to the pool during that round. You sure everything was working as expected during that round for you? I'm guessing that since the next round shows results that it may not be the problem you were seeing, but thought I'd throw it out there just in case.
|
|
|
|
deagel
Member

Offline
Activity: 67
Merit: 10
|
 |
December 21, 2013, 09:22:43 AM |
|
Hi, i have a short question:
# Block found at Duration Total shares Your shares Your BTC reward Block # Block value Validity 21229 2013-12-21 00:36:48 9:39:26 4091124633 17590 0.00000000 276127 25.12559563 34 Bestätigungen ausstehend
My miner can't finished the block couse of an hardware problem but is it true that i get no reward or will it be calculated later?
thanks
deagel
|
|
|
|
kabopar
|
 |
December 21, 2013, 10:36:40 AM |
|
difficulty just rose to 1180923195 (30% increase)
|
|
|
|
|