usukan
Legendary
 Offline
Activity: 1587
Merit: 1002
|
 |
October 15, 2015, 03:17:55 AM
Last edit: October 15, 2015, 03:28:44 AM by usukan |
|
SLUSH scored this block according to Tradeblock too - but its missing in Slush stats etc Tradeblock https://tradeblock.com/bitcoin/block/378943Block Time 15 Oct 2015 15:21 (an hour ago) Confirmations 7 Miner Slush Chain Main Hash 000000000000000002857f062e635f1c6779e9dd6f85bfe528bfc8f352b33ca3 Difficulty 60.8B Nonce 2,318,222,444 Size 189,907 B Fee/size 32.10953256 sat/B Version 3 I guess Slush know if they hit it - or not? |
--
--
|
|
|
|
|
|
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
|
|
|
|
|
|
|
dmwardjr
Legendary
Offline
Activity: 1554
Merit: 1261
Crypto Trading Technical Analyst
|
|
October 15, 2015, 10:49:50 PM |
|
SLUSH scored this block according to Tradeblock too - but its missing in Slush stats etc Tradeblock https://tradeblock.com/bitcoin/block/378943Block Time 15 Oct 2015 15:21 (an hour ago) Confirmations 7 Miner Slush Chain Main Hash 000000000000000002857f062e635f1c6779e9dd6f85bfe528bfc8f352b33ca3 Difficulty 60.8B Nonce 2,318,222,444 Size 189,907 B Fee/size 32.10953256 sat/B Version 3 I guess Slush know if they hit it - or not? It says, ANTPOOL found this block...  |
Follow me on Trading View for excellent signals in Bitcoin/US dollar - Bitstamp - https://www.tradingview.com/u/WyckoffMode/. Will be on a paid subscription website soon with trading signals and technical education using Wyckoff Method in conjunction with Godmode and Stochastic RSI indicators for many more crypto currency pairs besides BTCUSD. You can also follow me on Twitter at https://twitter.com/ModeWyckoff |
|
|
|
Rikim4ru
|
|
October 15, 2015, 11:27:38 PM |
|
Yeah Antpool relayed. But someone added a coinbase signature to the block that read as 'Slush's pool is the BEST' so, some sites picked it wrong... Quite funny if you ask me... https://www.antpool.com/coinbase.htm |
|
|
|
|
|
Rikim4ru
|
|
October 15, 2015, 11:30:01 PM |
|
And can someone go kick the box and fix the luck plz?  |
|
|
|
|
|
|
|
Lucko
|
|
October 16, 2015, 05:56:28 PM |
|
What is the story with all orphans? Is this Slush not looking at what blocks he mined and looking at coinbase or do we really get 1 a day?
|
|
|
|
|
|
Rikim4ru
|
|
October 16, 2015, 06:01:05 PM |
|
Just some salt on the bad luck xD
|
|
|
|
|
|
Lucko
|
|
October 16, 2015, 09:42:01 PM |
|
Just some salt on the bad luck xD
You know that for sure or are you just guessing. 0.5% is normal, 8 to 9% is not... |
|
|
|
|
|
|
|
|
|
|
doubletap1911
Newbie
Offline
Activity: 12
Merit: 0
|
|
October 18, 2015, 08:13:47 PM |
|
Does anyone see these Orphaned blocks as an attack by some of these Chinese Pools (specifically Antminer)?
|
|
|
|
|
eleuthria
Legendary
Offline
Activity: 1750
Merit: 1007
|
|
October 18, 2015, 08:25:38 PM |
|
Does anyone see these Orphaned blocks as an attack by some of these Chinese Pools (specifically Antminer)?
More likely it's just Slush's pool backend not updating to other blocks on the network fast enough (or being really slow in releasing its own blocks). He's the only one having such absurd orphan rates, the problem is on his end. |
RIP BTC Guild, April 2011 - June 2015
|
|
|
-ck
Legendary
Offline
Activity: 3164
Merit: 1333
Ruu \o/
|
|
October 18, 2015, 08:42:58 PM |
|
Does anyone see these Orphaned blocks as an attack by some of these Chinese Pools (specifically Antminer)?
More likely it's just Slush's pool backend not updating to other blocks on the network fast enough (or being really slow in releasing its own blocks). He's the only one having such absurd orphan rates, the problem is on his end. Presumably everything has slowed down due to the extra load of having so much hashrate on his pool. Since slush's pool code is python, it's likely just the slowdown of python not scaling to the greater number of clients it's seeing. He either needs more mining nodes or better software. From memory, slush's pool used to prioritise which clients got block updates first - since it takes time to send updates to all the miners, he prioritised the biggest miners first so all the small miners used to get the block change later. Perhaps even that workaround is no longer enough. |
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
|
|
|
|
OneInchWonder
|
|
October 18, 2015, 08:49:38 PM |
|
Im small time trying out this Bitcoin mining.
Suck to put in the hours and not get anything but shit happens.
|
get.uber.com/drive/?invite_code=brianp6308ue
|
|
|
eleuthria
Legendary
Offline
Activity: 1750
Merit: 1007
|
|
October 18, 2015, 08:52:40 PM |
|
Presumably everything has slowed down due to the extra load of having so much hashrate on his pool. Since slush's pool code is python, it's likely just the slowdown of python not scaling to the greater number of clients it's seeing. He either needs more mining nodes or better software.
From memory, slush's pool used to prioritise which clients got block updates first - since it takes time to send updates to all the miners, he prioritised the biggest miners first so all the small miners used to get the block change later. Perhaps even that workaround is no longer enough.
I'd assume something else is the issue. I highly doubt he has more active miners than ever, just higher speed ones. There's way fewer small fries out there today than there were a year or more ago. In a proper implementation of vardiff, the speed of connected miners should have absolutely no impact on actual server load, only the number of miners in general. |
RIP BTC Guild, April 2011 - June 2015
|
|
|
-ck
Legendary
Offline
Activity: 3164
Merit: 1333
Ruu \o/
|
|
October 18, 2015, 09:05:37 PM |
|
Presumably everything has slowed down due to the extra load of having so much hashrate on his pool. Since slush's pool code is python, it's likely just the slowdown of python not scaling to the greater number of clients it's seeing. He either needs more mining nodes or better software.
From memory, slush's pool used to prioritise which clients got block updates first - since it takes time to send updates to all the miners, he prioritised the biggest miners first so all the small miners used to get the block change later. Perhaps even that workaround is no longer enough.
I'd assume something else is the issue. I highly doubt he has more active miners than ever, just higher speed ones. There's way fewer small fries out there today than there were a year or more ago. In a proper implementation of vardiff, the speed of connected miners should have absolutely no impact on actual server load, only the number of miners in general. Well, probably that in combination with bitcoinds that haven't been optimised to cope in this transaction spam environment which can cause massive mempool and cpu blowouts and subsequently very slow block changes/getblocktemplate calls. |
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
|
|
|
doubletap1911
Newbie
Offline
Activity: 12
Merit: 0
|
|
October 18, 2015, 09:17:38 PM |
|
In an email reply I received from Slush inquiring about the abnormally high invalid blocks he responded by stating "it was a matter of chance to end up with invalid block". And additionally stating "We don't have direct impact over this behavior. Invalid blocks are natural part of the Blockchain ecosystem..."
Do all of you agree with this?
|
|
|
|
|
-ck
Legendary
Offline
Activity: 3164
Merit: 1333
Ruu \o/
|
|
October 18, 2015, 09:23:37 PM |
|
In an email reply I received from Slush inquiring about the abnormally high invalid blocks he responded by stating "it was a matter of chance to end up with invalid block". And additionally stating "We don't have direct impact over this behavior. Invalid blocks are natural part of the Blockchain ecosystem..."
Do all of you agree with this?
It is an expected phenomenon of the way blocks propagate that orphans will eventually occur, but it is the responsibility of the pool owner to optimise their design to minimise this effect. Having orphans is expected, yes, but having a high rate of orphans is not expected. Check the orphan rates of other pools. The percentage should be about the same for all pools, irrespective of their size, though statistically it would be hard to get an accurate percentage on smaller pools simply because of the number of blocks solved. |
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel
2% Fee Solo mining at solo.ckpool.org
-ck
|
|
|
eleuthria
Legendary
Offline
Activity: 1750
Merit: 1007
|
|
October 18, 2015, 09:25:40 PM |
|
In an email reply I received from Slush inquiring about the abnormally high invalid blocks he responded by stating "it was a matter of chance to end up with invalid block". And additionally stating "We don't have direct impact over this behavior. Invalid blocks are natural part of the Blockchain ecosystem..."
Do all of you agree with this?
There will always be *some* chance involved in orphan blocks. But he's lyingdishonest in saying that you don't have direct impact over the behavior. If your orphan rate is above ~1%, you have something wrong. EDIT: 9 of his last 200 blocks have been orphaned. There is CLEARLY something wrong with either the hardware, software, or network level for Slush. |
RIP BTC Guild, April 2011 - June 2015
|
|
|
|
