EclipseMC has been requesting difficulty ~10 shares, but has been crediting only 1 share per submission in their UI. This is particularly troubling given they advertise VARDIFF, even though I haven't observed difficulty change notifications beyond the initial one via network traces.
Anyone else observing this?
i suspect everyone is, in order to make payouts fair, by giving 1 share per 10 difficulty share submission just a wild stab in the dark though |
|
|
|
|
i don't think it is.
unless you list an ebay link in tandem with a bitcoin price to close your ebay auction
it doesn't make sense otherwise
|
|
|
|
is it normal to always only have 6 out connections? i mean, every once in a while i will see 7 or 8, but the majority of the time its only 6.
Im trying to find ways to really improve performance. I had an older machine running my node with just ubuntu server, but my efficiency was terrible, less than 80% after 48 hours. So i switched up to my windows laptop and currently running over 100% at just under 48 hours. my latency has also decreased. but i have only produced 1 share with 13gh/s. When i was running on my slower server i had produced nearly 5 shares 1 orphan in 48 hours.
I just think something is wrong here but i cant pinpoint it.
71.91.202.165:9332 is my node running on a 30Mbps cable connection.
yeah, 6 is the default. restart p2pool and use --p2pool-node 5.9.24.81 and --p2pool-node 198.12.127.2 ... that'll give you 8 outgoing connections, with guaranteed connection to two good nodes the shares sound perfectly normal for 13gh/s... just a little bit unlucky (oh, and you got lucky before that.. isn't it like 12hrs per share on avg?) |
|
|
|
I'm about to install the bitcoin-qt client on the computer i'm running my miner through, I guess it takes a few days now... will it impair the efficiency of my asic machine? I want to join p2pool but I have one computer I work on, and one that does the mining (which I had to replace recently - thus - no client  ). If your machine is reasonably fast, it can run P2Pool, your miners, the lot. Anything with an i3 or better is fine. The main restriction with running your own node is bandwidth. The average DSL connection can't provide what p2pool and bitcoin need to keep your stale rate low. M You should define what the average DSL connection is (this changes wildly between countries). I have what I consider one (in my country >10/1 Mbps ADSL connections are common) and I don't have any problem with my stale rate (obviously I changed the default settings of both bitcoind and p2pool). or so you say... You should define what you consider a problematic stale rate. re: gogxmagog - the cost of running a node locally can possibly offset any fees or extra DOA incurred by pointing at a public node instead, depending on the cost of your elec and if you normally keep that system running 24/7, I guess. I can mine @ a 200ms latency node and get about 2% DOA. Dunno what ASIC you have, some of them have a few seconds latency, which would be useless w/ p2pool. Some don't. re: my PMs, I'll answer them a little bit later |
|
|
|
Hoe? Whats up in the network? I become now many Rejected s ? And the output changes?? [2013-11-05 22:42:04] Accepted 0b02017e Diff 23/10 AMU 25 pool 0 <-00000001.acc6dd6e M:P D:10.000 G:22:41:52:0.052 C:9.970 (-1383687712.334) W:1383687724.441 (0.002) S:0.053 R:22:42:04
[2013-11-05 22:42:06] Rejected 11a44206 Diff 15/10 AMU 1 pool 0 <-00000001.acc6dd6e M:P D:10.000 G:22:41:52:0.052 C:7.633 (-1383687712.334) W:1383687726.276 (0.002) S:0.064 R:22:42:06
[2013-11-05 22:42:07] Rejected 0186c434 Diff 168/10 AMU 23 pool 0 <-00000001.acc6dd6e M:P D:10.000 G:22:41:52:0.052 C:6.865 (-1383687712.334) W:1383687727.014 (0.002) S:0.076 R:22:42:07
[2013-11-05 22:42:10] Rejected 0b6f31e9 Diff 22/10 AMU 22 pool 0 <-00000001.acc6dd6e M:P D:10.000 G:22:41:52:0.052 C:10.681 (-1383687712.334) W:1383687730.803 (0.001) S:0.059 R:22:42:10
[2013-11-05 22:42:12] Rejected 0d3fc2a8 Diff 19/10 AMU 32 pool 0 <-00000001.acc6dd6e M:P D:10.000 G:22:41:52:0.052 C:10.704 (-1383687712.334) W:1383687732.111 (0.005) S:0.059 R:22:42:12
[2013-11-05 22:42:15] Rejected 129b1ccb Diff 14/10 AMU 11 pool 0 <-00000001.acc6dd6e M:P D:10.000 G:22:41:52:0.052 C:14.013 (-1383687712.334) W:1383687735.873 (0.003) S:0.088 R:22:42:15
[2013-11-05 22:42:16] Rejected 10b5e94e Diff 15/10 AMU 10 pool 0 <-00000001.acc6dd6e M:P D:10.000 G:22:41:52:0.052 C:21.693 (-1383687712.334) W:1383687736.268 (0.003) S:0.073 R:22:42:16
[2013-11-05 22:42:16] Rejected 08deaf96 Diff 29/10 AMU 10 pool 0 <-00000001.acc6dd6e M:P D:10.000 G:22:41:52:0.052 C:23.747 (-1383687712.334) W:1383687736.317 (0.008) S:0.070 R:22:42:16
[2013-11-05 22:42:17] Rejected 0cdf1bfb Diff 20/10 AMU 6 pool 0 <-00000001.acc6dd6e M:P D:10.000 G:22:41:52:0.052 C:22.305 (-1383687712.334) W:1383687737.667 (0.002) S:0.067 R:22:42:17
[2013-11-05 22:42:20] Rejected 11e593d7 Diff 14/10 AMU 16 pool 0 <-00000001.acc6dd6e M:P D:10.000 G:22:41:52:0.052 C:19.162 (-1383687712.334) W:1383687740.021 (0.002) S:0.074 R:22:42:20 would have to see more of the log to know about the rejected stuff the output changes, i dunno, ive never seen anything like that. i turned off all p2pools again like 3 hrs ago though. is it some new git version? |
|
|
|
|
I'm done after half a dozen or so stales and 2 orphans
good luck =p
|
|
|
|
... but then wouldn't that be a new hash?
I think this is probably what happened -> 2013-11-06 08:37:30 (Approximate start time of hash) 2013-11-06 08:37:32 received block 0008685bf909d5316ac79e1b2f0f40f09af0c45219cd2f1776979acf8af8d30a 2013-11-06 08:37:37 CreateNewBlock(): total size 1225 (probably from a different thread) 2013-11-06 08:37:37 Found Hash 000f8536079f4f9368e295a1a4552fb27687ddd872444b07467dc86ca724d9b2 Yeah, I had forgotten about that. I've disabled hyperthreading on the machines I could & the rest are just running 4 now. Don't get a huge performance difference from the hyperthreaded *cores anyway |
|
|
|
They aren't even orphans though, they're coming up stale. I'm receiving the blocks, but it's working on the block prior
The latest one happened with 3 cores being used out of 8 on a xeon 1270v3
It's a similar issue - the code only checks for new transactions at the start of the hash, and doesn't interrupt ongoing hashes when new blocks come in. The code is not optimized and not designed to gracefully deal with these conditions. 2013-11-06 08:37:32 received block 0008685bf909d5316ac79e1b2f0f40f09af0c45219cd2f1776979acf8af8d30a
2013-11-06 08:37:32 Committing 2 changed transactions to coin database...
2013-11-06 08:37:32 SetBestChain: new best=0008685bf909d5316ac79e1b2f0f40f09af0c45219cd2f1776979acf8af8d30a height=2368 log2_work=23.210415 tx=2670 date=2013-11-06 08:37:06 progress=0.000053
2013-11-06 08:37:32 ProcessBlock: ACCEPTED
2013-11-06 08:37:32 received getdata for: block 0008685bf909d5316ac79e1b2f0f40f09af0c45219cd2f1776979acf8af8d30a limit 500
2013-11-06 08:37:32 received getdata for: block 0008685bf909d5316ac79e1b2f0f40f09af0c45219cd2f1776979acf8af8d30a limit 500
2013-11-06 08:37:32 received getdata for: block 0008685bf909d5316ac79e1b2f0f40f09af0c45219cd2f1776979acf8af8d30a limit 500
2013-11-06 08:37:32 received getdata for: block 0008685bf909d5316ac79e1b2f0f40f09af0c45219cd2f1776979acf8af8d30a limit 500
2013-11-06 08:37:32 received getdata for: block 0008685bf909d5316ac79e1b2f0f40f09af0c45219cd2f1776979acf8af8d30a limit 500
2013-11-06 08:37:32 received getdata for: block 0008685bf909d5316ac79e1b2f0f40f09af0c45219cd2f1776979acf8af8d30a limit 500
2013-11-06 08:37:32 received getdata for: block 0008685bf909d5316ac79e1b2f0f40f09af0c45219cd2f1776979acf8af8d30a limit 500
2013-11-06 08:37:32 received getdata for: block 0008685bf909d5316ac79e1b2f0f40f09af0c45219cd2f1776979acf8af8d30a limit 500
2013-11-06 08:37:32 received getdata for: block 0008685bf909d5316ac79e1b2f0f40f09af0c45219cd2f1776979acf8af8d30a limit 500
2013-11-06 08:37:32 received getdata for: block 0008685bf909d5316ac79e1b2f0f40f09af0c45219cd2f1776979acf8af8d30a limit 500
2013-11-06 08:37:32 received getdata for: block 0008685bf909d5316ac79e1b2f0f40f09af0c45219cd2f1776979acf8af8d30a limit 500
2013-11-06 08:37:32 received getdata for: block 0008685bf909d5316ac79e1b2f0f40f09af0c45219cd2f1776979acf8af8d30a limit 500
2013-11-06 08:37:32 received getdata for: block 0008685bf909d5316ac79e1b2f0f40f09af0c45219cd2f1776979acf8af8d30a limit 500
2013-11-06 08:37:32 received getdata for: block 0008685bf909d5316ac79e1b2f0f40f09af0c45219cd2f1776979acf8af8d30a limit 500
2013-11-06 08:37:32 received getdata for: block 0008685bf909d5316ac79e1b2f0f40f09af0c45219cd2f1776979acf8af8d30a limit 500
2013-11-06 08:37:32 received getdata for: block 0008685bf909d5316ac79e1b2f0f40f09af0c45219cd2f1776979acf8af8d30a limit 500
2013-11-06 08:37:32 received getdata for: block 0008685bf909d5316ac79e1b2f0f40f09af0c45219cd2f1776979acf8af8d30a limit 500
2013-11-06 08:37:32 received getdata for: block 0008685bf909d5316ac79e1b2f0f40f09af0c45219cd2f1776979acf8af8d30a limit 500
2013-11-06 08:37:32 received getdata for: block 0008685bf909d5316ac79e1b2f0f40f09af0c45219cd2f1776979acf8af8d30a limit 500
2013-11-06 08:37:32 received getdata for: block 0008685bf909d5316ac79e1b2f0f40f09af0c45219cd2f1776979acf8af8d30a limit 500
2013-11-06 08:37:32 received getdata for: block 0008685bf909d5316ac79e1b2f0f40f09af0c45219cd2f1776979acf8af8d30a limit 500
2013-11-06 08:37:32 received getdata for: block 0008685bf909d5316ac79e1b2f0f40f09af0c45219cd2f1776979acf8af8d30a limit 500
2013-11-06 08:37:32 received getdata for: block 0008685bf909d5316ac79e1b2f0f40f09af0c45219cd2f1776979acf8af8d30a limit 500
2013-11-06 08:37:32 received getdata for: block 0008685bf909d5316ac79e1b2f0f40f09af0c45219cd2f1776979acf8af8d30a limit 500
2013-11-06 08:37:32 received getdata for: block 0008685bf909d5316ac79e1b2f0f40f09af0c45219cd2f1776979acf8af8d30a limit 500
2013-11-06 08:37:32 received getdata for: block 0008685bf909d5316ac79e1b2f0f40f09af0c45219cd2f1776979acf8af8d30a limit 500
2013-11-06 08:37:32 received getdata for: block 0008685bf909d5316ac79e1b2f0f40f09af0c45219cd2f1776979acf8af8d30a limit 500
2013-11-06 08:37:33 received getdata for: block 0008685bf909d5316ac79e1b2f0f40f09af0c45219cd2f1776979acf8af8d30a limit 500
2013-11-06 08:37:33 received getdata for: block 0008685bf909d5316ac79e1b2f0f40f09af0c45219cd2f1776979acf8af8d30a limit 500
2013-11-06 08:37:33 received getdata for: block 0008685bf909d5316ac79e1b2f0f40f09af0c45219cd2f1776979acf8af8d30a limit 500
2013-11-06 08:37:33 received getdata for: block 0008685bf909d5316ac79e1b2f0f40f09af0c45219cd2f1776979acf8af8d30a limit 500
2013-11-06 08:37:33 received getdata for: block 0008685bf909d5316ac79e1b2f0f40f09af0c45219cd2f1776979acf8af8d30a limit 500
2013-11-06 08:37:33 received getdata for: block 0008685bf909d5316ac79e1b2f0f40f09af0c45219cd2f1776979acf8af8d30a limit 500
2013-11-06 08:37:33 received getdata for: block 0008685bf909d5316ac79e1b2f0f40f09af0c45219cd2f1776979acf8af8d30a limit 500
2013-11-06 08:37:33 received getdata for: block 0008685bf909d5316ac79e1b2f0f40f09af0c45219cd2f1776979acf8af8d30a limit 500
2013-11-06 08:37:34 received getdata for: block 0008685bf909d5316ac79e1b2f0f40f09af0c45219cd2f1776979acf8af8d30a limit 500
2013-11-06 08:37:37 testHash 80a9a8e430a940eab285ee66cf7e358cb39bf822ae03ab316cb2bb743f7dc411
2013-11-06 08:37:37 Hash Target 000fff0000000000000000000000000000000000000000000000000000000000
2013-11-06 08:37:37 CreateNewBlock(): total size 1225
2013-11-06 08:37:37 Running ProtoSharesMiner with 2 transactions in block (421 bytes)
2013-11-06 08:37:37 testHash 000f8536079f4f9368e295a1a4552fb27687ddd872444b07467dc86ca724d9b2
2013-11-06 08:37:37 Hash Target 000fff0000000000000000000000000000000000000000000000000000000000
2013-11-06 08:37:37 Found Hash 000f8536079f4f9368e295a1a4552fb27687ddd872444b07467dc86ca724d9b2
2013-11-06 08:37:37 hash 000f8536079f4f9368e295a1a4552fb27687ddd872444b07467dc86ca724d9b2
2013-11-06 08:37:37 hash2 000f8536079f4f9368e295a1a4552fb27687ddd872444b07467dc86ca724d9b2
2013-11-06 08:37:37 ProtoSharesMiner:
2013-11-06 08:37:37 proof-of-work found
2013-11-06 08:37:37 CBlock(hash=000f8536079f4f9368e295a1a4552fb27687ddd872444b07467dc86ca724d9b2, ver=2, hashPrevBlock=000a1f6692b2a78e89ab3e82bd04fead89e240774ef9203e9c293825133f485f, hashMerkleRoot=fc1c23eed0a5f6c77b1a2d34247c6dc0f34de96c4ae416f8227d1e33e93440b5, nTime=1383727041, nBits=20000fff, nNonce=2, vtx=1, birthdayA=55398462, birthdayB=64046174)
2013-11-06 08:37:37 CTransaction(hash=fc1c23eed0a5f6c77b1a2d34247c6dc0f34de96c4ae416f8227d1e33e93440b5, ver=1, vin.size=1, vout.size=1, nLockTime=0)
2013-11-06 08:37:37 generated 47.50
2013-11-06 08:37:37 ERROR: ProtoSharesMiner : generated block is stale ... but then wouldn't that be a new hash? ed: Oh, I see. There's one going for each thread. I guess that means it's probably better to disable hyperthreading |
|
|
|
There's a lot of orphans right now because the difficultly is still low and we're getting new blocks every 30 seconds. This was unexpected and should be considered atypical conditions. This will become much less of an issue after difficulty adjustment at block 4032.
They aren't even orphans though, they're coming up stale. I'm receiving the blocks, but it's working on the block prior The latest one happened with 3 cores being used out of 8 on a xeon 1270v3 |
|
|
|
|
I'm getting about 100 hashes per minute in total between all my machines, but so far they've only generated 4 stales.
Is the crap in the git messed up?
|
|
|
|
|
Here's another
2013-11-06 08:37:01 received block 000a1f6692b2a78e89ab3e82bd04fead89e240774ef9203e9c293825133f485f
2013-11-06 08:37:32 received block 0008685bf909d5316ac79e1b2f0f40f09af0c45219cd2f1776979acf8af8d30a
2013-11-06 08:37:37 CreateNewBlock(): total size 1225
2013-11-06 08:37:37 Running ProtoSharesMiner with 2 transactions in block (421 bytes)
2013-11-06 08:37:37 testHash 000f8536079f4f9368e295a1a4552fb27687ddd872444b07467dc86ca724d9b2
2013-11-06 08:37:37 Hash Target 000fff0000000000000000000000000000000000000000000000000000000000
2013-11-06 08:37:37 Found Hash 000f8536079f4f9368e295a1a4552fb27687ddd872444b07467dc86ca724d9b2
2013-11-06 08:37:37 hash 000f8536079f4f9368e295a1a4552fb27687ddd872444b07467dc86ca724d9b2
2013-11-06 08:37:37 hash2 000f8536079f4f9368e295a1a4552fb27687ddd872444b07467dc86ca724d9b2
2013-11-06 08:37:37 ProtoSharesMiner:
2013-11-06 08:37:37 proof-of-work found
hash: 000f8536079f4f9368e295a1a4552fb27687ddd872444b07467dc86ca724d9b2
target: 000fff0000000000000000000000000000000000000000000000000000000000
2013-11-06 08:37:37 CBlock(hash=000f8536079f4f9368e295a1a4552fb27687ddd872444b07467dc86ca724d9b2, ver=2, hashPrevBlock=000a1f6692b2a78e89ab3e82bd04fead89e240774ef9203e9c293825133f485f, hashMerkleRoot=fc1c23eed0a5f6c77b1a2d34247c6dc0f34de96c4ae416f8227d1e33e93440b5, nTime=1383727041, nBits=20000fff, nNonce=2, vtx=1, birthdayA=55398462, birthdayB=64046174)
2013-11-06 08:37:37 CTransaction(hash=fc1c23eed0a5f6c77b1a2d34247c6dc0f34de96c4ae416f8227d1e33e93440b5, ver=1, vin.size=1, vout.size=1, nLockTime=0)
CTxIn(COutPoint(0000000000000000000000000000000000000000000000000000000000000000, 4294967295), coinbase 0240090102062f503253482f)
CTxOut(nValue=47.50000000, scriptPubKey=029f877979dca68b5ee46e6f103ea8)
vMerkleTree: fc1c23eed0a5f6c77b1a2d34247c6dc0f34de96c4ae416f8227d1e33e93440b5
2013-11-06 08:37:37 generated 47.50
2013-11-06 08:37:37 ERROR: ProtoSharesMiner : generated block is stale
|
|
|
|
|
I found one and it said it was stale, and it doesn't even show up in listtransactions?
How does that happen?
2013-11-06 08:20:43 received block 0007b9a2988c14af77519a00c78142c7642d79525ed35b03b9d516b7a4fb092f
2013-11-06 08:21:00 CreateNewBlock(): total size 1000
2013-11-06 08:21:00 Running ProtoSharesMiner with 1 transactions in block (196 bytes)
2013-11-06 08:21:00 testHash 65c93a0c83f0ba78a50a920b4799bf567d981dcdf129ff2ad447f859db63850b
2013-11-06 08:21:00 Hash Target 000fff0000000000000000000000000000000000000000000000000000000000
2013-11-06 08:21:06 testHash 00014adce04df026efea4dc19b2ae0b2917e1d8ca2c787170e80acd16eae8219
2013-11-06 08:21:06 Hash Target 000fff0000000000000000000000000000000000000000000000000000000000
2013-11-06 08:21:06 Found Hash 00014adce04df026efea4dc19b2ae0b2917e1d8ca2c787170e80acd16eae8219
2013-11-06 08:21:06 hash 00014adce04df026efea4dc19b2ae0b2917e1d8ca2c787170e80acd16eae8219
2013-11-06 08:21:06 hash2 00014adce04df026efea4dc19b2ae0b2917e1d8ca2c787170e80acd16eae8219
2013-11-06 08:21:06 ProtoSharesMiner:
2013-11-06 08:21:06 proof-of-work found
hash: 00014adce04df026efea4dc19b2ae0b2917e1d8ca2c787170e80acd16eae8219
target: 000fff0000000000000000000000000000000000000000000000000000000000
2013-11-06 08:21:06 CBlock(hash=00014adce04df026efea4dc19b2ae0b2917e1d8ca2c787170e80acd16eae8219, ver=2, hashPrevBlock=000fb27cf64af03bce75d45916271a31405efb2f7862d7786b35224fb82989ca, hashMerkleRoot=
5874343e3181b7c2513b53bc804747a46546364c743b8b2fa818de4f4d43415e, nTime=1383726041, nBits=20000fff, nNonce=2, vtx=1, birthdayA=40641297, birthdayB=57044241)
2013-11-06 08:21:06 CTransaction(hash=5874343e3181b7c2513b53bc804747a46546364c743b8b2fa818de4f4d43415e, ver=1, vin.size=1, vout.size=1, nLockTime=0)
CTxIn(COutPoint(0000000000000000000000000000000000000000000000000000000000000000, 4294967295), coinbase 0224090109062f503253482f)
CTxOut(nValue=47.50000000, scriptPubKey=02638e0ba8489649031536b45be330)
vMerkleTree: 5874343e3181b7c2513b53bc804747a46546364c743b8b2fa818de4f4d43415e
2013-11-06 08:21:06 generated 47.50
2013-11-06 08:21:06 ERROR: ProtoSharesMiner : generated block is stale
2013-11-06 08:21:06 CreateNewBlock(): total size 1000
Oh, I see.
debug.log:2013-11-06 08:20:10 received block 000fb27cf64af03bce75d45916271a31405efb2f7862d7786b35224fb82989ca (edited out IP)
interesting
i guess i should not use all 8 cores
ed: actually, shouldn't it create a new block after each new block that is found? i have seen there is sometimes a delay of up to 10 seconds
err, it did. wtf was it working on a block that was received 56s prior? it received one at 20:43 and created a new block at 21:00, why was it not based on the latest block?
|
|
|
|
|
it's strange when i look at all these european nodes and they're all at 7%+ orphan rate, yet only 3 ppl have even ever asked me about how to fix this
though i'd say it requires more like 8 outgoing connections to be a sure thing
|
|
|
|
|
Total
Area: 639PH
orphan
Area: 15.4PH (2.4% total)
8.33% is high orphan rate that can be fixed rather easily, that fellow in Taiwan that runs a node has a 7.34% orphan rate over 1648 shares
anyone in western or eastern europe (also including novgorod and basically anything else west of that) should be at 5% or less
i guess 36 shares isn't a very large sample though, maybe just got unlucky with the, uh, pot luck block switches
|
|
|
|
I just don't understand why anyone would join a guild that's so big. We all know a 51% attack isn't exactly that dangerous, but that doesn't mean there aren't other types of effects from giving so much power to one group.
And thus the cycle continues. Now even 30% warrants outrage, a value that nobody had seemed to have an issue with for all of 2011 and 2012 when it was Slush or Deepbit with 30%. Hell, for a long time it was 2 pools controlling 30%+ each, double the danger! i remember a lot of bitching about deepbit in 2011. not so much slush The bitching about Deepbit was when they were ~45%. And it wasn't even that loud until they actually *had* 51%. BTC Guild is 29.8% ( http://blockorigin.pfoe.be/chart.php). Well, I don't think you should have to defend the fact that your pool is successful, shrug.. Even if it did get to 51%, I suspect the only benefit you could take advantage of w/o crashing the price would just be that you'd be able to win even more of the orphan "races" just by solving another block on top of the one that had a possibility of being orphaned.. any other types of chicanery would most likely be detected pretty fast & I personally dont see the incentive of destroying one's own source of income (or the value of their current assets) |
|
|
|
I just don't understand why anyone would join a guild that's so big. We all know a 51% attack isn't exactly that dangerous, but that doesn't mean there aren't other types of effects from giving so much power to one group.
And thus the cycle continues. Now even 30% warrants outrage, a value that nobody had seemed to have an issue with for all of 2011 and 2012 when it was Slush or Deepbit with 30%. Hell, for a long time it was 2 pools controlling 30%+ each, double the danger! i remember a lot of bitching about deepbit in 2011. not so much slush I just don't understand why anyone would join a guild that's so big. ignorance? i've always figured most of the biggest asic miners nowadays didn't even know about bitcoins until this year (outside of the companies themselves hashing) well, wait, let me edit this again. i'm not saying ignorance based on size (well, indirectly I suppose). more like "the more often I get paid, the more I make" |
|
|
|
|
Right now, it's more important that you avoid requesting a block from one of the vbitcoin nodes
I imagine it's how blockchain picked up the 268083 as an orphan before receiving 268082
re: bigger blocks. i'm sure most of these pools are on good connections, so it's probably not much of an issue. if you're solo mining on limited bandwidth, then, yeah, you'd want to reduce the size.
|
|
|
|
|
there's a serious issue w/ propagation here, too many big miners on private nodes, probably with the default random 6 connections.
28 out of the last 30 shares received by 195.72.200.193 came from one of my 3 nodes, which I just restarted 90m ago... 195.72.200.193 is running @ 5thash. It had 5 incoming connections, 9 good shares, 2 orphans, 3 doa after running for an hour.
WTF does it only have 5 incoming connections for? I bet 2 or 3 of those were even just random connections. Maybe 2 or 3 on --p2pool-node? that's just absurd
then again, I guess p2pool is a bit of a microcosm of the bigger pools, right? so it's good for the 5thash pool to get lots of orphans and DOAs? shrug.
if you want to improve your own efficiency rating, --p2pool-node 5.9.24.81 and --p2pool-node 198.12.127.2 .. they are hashing at a combined 8ghash right now, so it doesn't benefit those specific pools in any meaningful way
for any other person that does, the person that doesn't loses efficiency relative to that person & hence to the pool as a whole (or at least until some get DDoSed again)
|
|
|
|
Hey all, sorry about email notifications not being sent! The issue is now resolved, and you should receive 2FA links again.
I'm guessing you are receiving some orphan blocks? (the latest being 268082 and 268083 out of order) I'm not smart like those people at ETH Zurich, so I don't know how they always find your IP to connect to, but... those nodes all report blocks and answer requests to relay them, but they never send. |
|
|
|
|
Show Posts
