Now that we've found a block I'll be restarting the pool shortly for some minor updates.
Restart complete; mine on! |
|
|
|
[2018-06-19 16:11:09.744] Possible block solve diff 163794712999854.031250 !
[2018-06-19 16:11:09.880] BLOCK ACCEPTED!
[2018-06-19 16:11:09.886] Solved and confirmed block 528266 by 1MS6FJe8JyvcKBjbRnkhJon3TsfyAn4D9W
[2018-06-19 16:11:09.886] User 1MS6FJe8JyvcKBjbRnkhJon3TsfyAn4D9W:{"hashrate1m": "59.1T", "hashrate5m": "56.4T", "hashrate1hr": "43.2T", "hashrate1d": "37.1T", "hashrate7d": "36.6T"}
[2018-06-19 16:11:09.886] Worker 1MS6FJe8JyvcKBjbRnkhJon3TsfyAn4D9W:{"hashrate1m": "59.1T", "hashrate5m": "56.4T", "hashrate1hr": "43.2T", "hashrate1d": "37.1T", "hashrate7d": "36.6T"}
[2018-06-19 16:11:09.888] Block solved after 6283697449144 shares at 123.8% diff
|
|
|
|
[2018-06-19 21:34:12.187] Possible block solve diff 154102402115128.281250 !
[2018-06-19 21:34:12.287] BLOCK ACCEPTED!
[2018-06-19 21:34:12.736] Solved block 528272 by 36JMs8rogpizjkkp6eeKMmm3SLbSNo5H9V.0
[2018-06-19 21:34:12.736] User 36JMs8rogpizjkkp6eeKMmm3SLbSNo5H9V:{"hashrate1m": "177P", "hashrate5m": "172P", "hashrate1hr": "167P", "hashrate1d": "157P", "hashrate7d": "104P"}
[2018-06-19 21:34:12.736] Worker 36JMs8rogpizjkkp6eeKMmm3SLbSNo5H9V.0:{"hashrate1m": "137P", "hashrate5m": "133P", "hashrate1hr": "129P", "hashrate1d": "118P", "hashrate7d": "82.2P"}
[2018-06-19 21:42:48.523] Hash for block height 528272 confirms block was CONFIRMED
|
|
|
|
Thank you for the extensive reply, Con. My only question is why would this issue start to occur after a reboot?
In my case I was watching about a dozen of the T1, all of them 16 TH for a couple weeks, until they were all rebooted (power off for 5-10 mins, then back on). After this, 4 miners came back up with only 1 board and there are 4 more that only have 2. Tried rebooting them all but exact same results.
I made sure to check pool stats to confirm the hashrate drop. Any idea why those faulty boards were still able to keep hashing until the miners were rebooted?
Inrush of current, thermal changes, hot vs cold, who knows. The 10nm chips are very fussy. Might be worth powering them down to let them cool and then start again. Also make sure you're on the latest firmware; some earlier ones weren't as reliable at starting them. They're a royal pain in the arse to start reliably... |
|
|
|
|
It's exactly as you've said - the chain isn't working. When the controller can no longer talk to the mining board, it has communication errors. The driver tries to reset the comms channel and then tries to re-init the board. If it doesn't succeed it shuts down and tries restarting cgminer. If it can't communicate with the board during the extensive init sequence on driver startup, the board will never come up.
|
|
|
|
[2018-06-15 08:22:49.209] Hash for block height 527537 confirms block was CONFIRMED
[2018-06-17 21:40:49.144] Possible block solve diff 10488367652950.886719 !
[2018-06-17 21:40:49.253] BLOCK ACCEPTED!
[2018-06-17 21:40:49.265] Solved block 527954 by 36JMs8rogpizjkkp6eeKMmm3SLbSNo5H9V.0
[2018-06-17 21:40:49.265] User 36JMs8rogpizjkkp6eeKMmm3SLbSNo5H9V:{"hashrate1m": "142P", "hashrate5m": "139P", "hashrate1hr": "138P", "hashrate1d": "137P", "hashrate7d": "86.8P"}
[2018-06-17 21:40:49.265] Worker 36JMs8rogpizjkkp6eeKMmm3SLbSNo5H9V.0:{"hashrate1m": "101P", "hashrate5m": "98.5P", "hashrate1hr": "97.9P", "hashrate1d": "98.5P", "hashrate7d": "71.2P"}
[2018-06-17 21:49:35.785] Hash for block height 527954 confirms block was CONFIRMED
|
|
|
|
Hi all, I have pointed my miner to solo.ckpool.org respectively de.ckpool.org. But as you can see in the screenhot the rejected value is extreme high:  If I point my miner to viaBTC (also in solo mode) the rejected value is zero:  Is this normal on ckpool.org or is there something I can do about it? Thank you in advance! The shitmain drivers are broken. They forked their driver off an ancient version of cgminer. My guess is they are confusing other messages from the pool as being rejected shares - if you can read the console output it will probably say something like rejected untracked share when it fact it's a ping from the pool. If your accepted share rate is fine then you can basically ignore the rejected shares. |
|
|
|
My derp was around 001 Now it's 0001 My placement went from the fifties deferred payment to the six hundreds?  ? If we find a block on average every 10 days you're entitled to .001; if we find a block on average every day you're entitled to 0.0001. It's as simple as that. |
|
|
|
When luck's good, it's good... If only there was a way to guarantee it remained this way... Anyway.. 16.4% diff BLOCK! woohoo. [2018-06-15 08:20:11.716] Possible block solve diff 45078472585776.453125 !
[2018-06-15 08:20:11.828] BLOCK ACCEPTED!
[2018-06-15 08:20:12.188] Solved block 527537 by 36JMs8rogpizjkkp6eeKMmm3SLbSNo5H9V.0
[2018-06-15 08:20:12.188] User 36JMs8rogpizjkkp6eeKMmm3SLbSNo5H9V:{"hashrate1m": "141P", "hashrate5m": "140P", "hashrate1hr": "138P", "hashrate1d": "108P", "hashrate7d": "63.3P"}
[2018-06-15 08:20:12.188] Worker 36JMs8rogpizjkkp6eeKMmm3SLbSNo5H9V.0:{"hashrate1m": "104P", "hashrate5m": "104P", "hashrate1hr": "102P", "hashrate1d": "86.4P", "hashrate7d": "58.5P"}
[2018-06-15 08:22:49.209] Hash for block height 527537 confirms block was CONFIRMED
Full payout details: http://ckpool.org/blocks/527537.confirmed |
|
|
|
What happens during an orphan block? Do coins appear in our wallets (as unmatured) then get taken away when its officially orphaned?
Only if you see that block first before the other one that orphans it. In this situation you wouldn't have seen anything. |
|
|
|
Wallet fully synced and yet no TX for latest payout? strange.
"17zyuMZzuD4cd4WCP24WcnnMcBkYiRc3es": 0.01627649
It's there with 9 confirmations, like all the rest of the rewards: https://btc.com/17zyuMZzuD4cd4WCP24WcnnMcBkYiRc3esHope your wallet isn't bogus. |
|
|
|
Would have been a double block day if not for the orphan!
Still might be. |
|
|
|
Making up for the orphan at 54.6% diff  This time it wasn't Halong! One of our regular miners (but with a Dragonmint T1 nonetheless). [2018-06-15 02:07:52.153] Possible block solve diff 13236048667151.658203 !
[2018-06-15 02:07:52.242] BLOCK ACCEPTED!
[2018-06-15 02:07:52.251] Solved block 527499 by 1J17t8CjjVwegqn6Y4JC7osA8fNsuz8z5D.DMT11
[2018-06-15 02:07:52.251] User 1J17t8CjjVwegqn6Y4JC7osA8fNsuz8z5D:{"hashrate1m": "129T", "hashrate5m": "128T", "hashrate1hr": "124T", "hashrate1d": "118T", "hashrate7d": "105T"}
[2018-06-15 02:07:52.251] Worker 1J17t8CjjVwegqn6Y4JC7osA8fNsuz8z5D.DMT11:{"hashrate1m": "15.4T", "hashrate5m": "13.7T", "hashrate1hr": "12.9T", "hashrate1d": "9.85T", "hashrate7d": "8.94T"}
[2018-06-15 02:17:24.830] Hash for block height 527499 confirms block was CONFIRMED
Full payout details: http://ckpool.org/blocks/527499.confirmed |
|
|
|
Our difficulty % was around 125%
"solvedby": "36JMs8rogpizjkkp6eeKMmm3SLbSNo5H9V",
"date": "[2018-06-13 13:28:53.840]",
"hash": "00000000000000000031552854fde522e73177585ecd463dea64fb503c4e0083",
"shares": 6085301242740,
"diff": 123.2 I was wondering where is this 'solvedby' URL? Thanks! |
|
|
|
Watching the chain to see if we win a double race... likely the only adrenaline-inducing thing left in mining.  Watching the pool you mine in lose that race... likely the worst feeling left in mining.  Alas it was a foregone conclusion. It wasn't much of an orphan race at all, so even the fast block change code in the pool couldn't have prevented us losing that one. For people wondering what he's talking about, we had a block orphaned. What happened was the block had already been solved by another pool, but a miner submitted a stale share 700ms later that was also a block solve. There was almost no chance it was going to be successful, but the pool will try to use it as a block solve anyway, forcing bitcoind to accept the block, in the unlikely event it wins the orphan race (or solves two blocks back to back). Realistically the pool can just ignore it since it was stale but we'll try anything to get a block. Here are the pool logs where you can see it says it's submitting a stale share block solve: [2018-06-14 18:11:25.412] Block hash changed to 00000000000000000037e634734805d4a48f7d50125ecc55a2f137e2722a32f3
[2018-06-14 18:11:26.100] Possible stale share block solve diff 10130992321539.841797 !
[2018-06-14 18:11:26.100] Submitting block data!
[2018-06-14 18:11:26.107] SUBMIT BLOCK RETURNED: inconclusive
[2018-06-14 18:11:26.171] Hash for block height 527471 confirms block was ACCEPTED
[2018-06-14 18:11:26.176] Solved block 527471 by 36JMs8rogpizjkkp6eeKMmm3SLbSNo5H9V.0
[2018-06-14 18:11:26.176] User 36JMs8rogpizjkkp6eeKMmm3SLbSNo5H9V:{"hashrate1m": "142P", "hashrate5m": "142P", "hashrate1hr": "136P", "hashrate1d": "83.7P", "hashrate7d": "56.6P"}
[2018-06-14 18:11:26.176] Worker 36JMs8rogpizjkkp6eeKMmm3SLbSNo5H9V.0:{"hashrate1m": "107P", "hashrate5m": "107P", "hashrate1hr": "102P", "hashrate1d": "73.4P", "hashrate7d": "54.6P"}
[2018-06-14 18:11:26.272] Block hash changed to 0000000000000000001bc87b3d85516a0b00bf873a43dbef986125c269c210d8
[2018-06-14 18:32:31.978] Hash for block height 527471 confirms block was ORPHANED
At the end the pool sees that it lost the orphan race and moves to the new block. Unfortunate, but one of the realities of mining. The only fortunate part is the pool code already takes into account what should happen in the case of an orphan, to prevent the interleaved payouts getting out of sync. It will also NOT artificially reset the diff back to 0% since we didn't win a block. You can see the full details of what would have been a block in this sadly named block file: http://ckpool.org/blocks/527471.orphaned |
|
|
|
Now that we have to deal with the extensions to support asicboost
Has anyone looked into if its possible to implement our own pool server supporting the extensions proxying to upstream pools that support coin switching?
If the upstream pool(s) don't support asciboost then a proxy won't help you. |
|
|
|
How does block withholding work? I always thought it would be the pool that did the withholding, is it the miner that does it instead? What nefarious purposes can hashrate be used for (besides block withholding)?
A pool stands nothing to gain by withholding a block - they lose the block reward! Block withholding works by the miner withholding the block from the pool, but still getting paid by the pool - that only works if the upstream pool pays you whether the pool finds blocks or not; i.e. for PPS only. The miner gets their payout regardless, but the pool gets nothing, thus harming the pool, but also advantageous to the miner is the fact it keeps mining difficulty lower. Pools have used their hashrate in the past to secretly merge mine other coins, including at least one known public instance of destroying an altcoin. The main concern with a pool getting enough hashrate is obviously double spending, but a pool would need to be 1/3 of the network hashrate or more so that's unlikely to happen just because of a high PPS rewards percentage... unless antpool started offering too high for comfort. |
|
|
|
Highest PPS that I know of is connectbtc 110% instead of Via and f2p at 105%(?) Also isnt via PPS+?
@110% im getting paid for shares for a 13.75BTC block which we havent even come close to hitting in the past 4+ months.
CK takes my halong T1 miners though as connect btc is bitmain owned and they wont be implementing ASICBoost anytime soon, so I happily split my miners between the 2. With luck, CK could be more profitable, or have more profitable months, but if TX fees stay low PPS seems to be the most profitable way to go.
If fees stay low, PPS from the pools will not be sustainable at that rate anyway since the money has to come from somewhere and the blocks won't be reimbursing them for the amount they give out, and it's not like they'd pay you to mine there unless they actually wanted your extra hashrate for nefarious purposes or something stupid. There was an analysis done many years ago by Organofcorti, who unfortunately is no longer active on the forums due to his family, that showed how much money in reserve a PPS pool would have to have to cope with the worst possible luck stretches and it was astoundingly high. Add to that the fact that PPS pools are the number one potential target for block withholding attacks, it's amazing that more haven't gone under (there are plenty of pools that have come and gone though.) |
|
|
|
What would be the benefit of joining a smaller pool like ck, over a larger pool like slush or kano. Is it just because reward share is higher when a block is solved? If so, does this just mean we are hoping to get lucky and go on a hot streak? I was under the impression that it all "evens out" over the long run. I am new to this and still learning !
0% fee, so saves more money over the long run. And yes, since you get paid for higher dif shares you can potentially earn more (or less) than other pools. In theory this pool is the 2nd most profitable. There is also coinbase generation meaning you don't need to wait to confirm your payout or worry about pool wallet hacks. Additionally because smaller payouts are interleaved it means you don't get lots of small fragmented payouts which ends up leading to bigger fees when you finally spend your coin. Finally even dust payouts eventually get paid out too. |
|
|
|
|
Show Posts
