hi eleuthria,
do you consider other algos?
i am mainly interested in CN which gets raped by poolhoppers lately (all pools are still prop) and i guess cpu/amd/nvidia-mineable coins with some value are a good add to your pool?
No plans at this time to add the other algorithms. |
|
|
|
What's happening with the PPLNS stats page? The 1+PH/s user has disappeared, but so have their stats. They still found the most blocks, even if they're no longer contributing to the pool.
The 1 PH/s user is either having major issues, or has left the pool (haven't been able to identify their speed on a pool that gives public user stats). The PPLNS detail view shows the exact shares submitted by each user for any individual shift. The rankings page only shows users active in the previous shift. The 1 PH/s+ user has had one unit coming on and off, just a few hundred GH/s, so they keep re-appearing on the Rankings page (shares+blocks found), but on the shift details they would be very low. |
|
|
|
 Rapid growth of GHash.IO mining pool, seen over the past few months, has been driven by our determination to offer innovative solutions within the Bitcoin ecosystem combined with significant investment in resource. Our investment, participation and highly motivated staff confirm it is our intention to help protect and grow the broad acceptance of Bitcoin and categorically in no way harm or damage it. We never have and never will participate in any 51% attack or double spend against Bitcoin. Still, we are against temporary solutions, which could repel a 51% threat. In any market, competition and innovation drives growth and that is particularly true in an emerging and disruptive environment such as Bitcoin. Successful and innovative companies cannot be expected to limit their growth or competitiveness as a direct result of their success. However, this is the situation we find ourselves in when faced with the community perception of the threat of a 51% attack on Bitcoin. Asking our users to not use our services or to use competing solutions is not conducive to fostering innovation. Implementing a pool fee to our pool contradicts principles of our operation from the very launch of GHash.IO. It also does not address the core issue only pushing the problem a few weeks or months down the road when another pool or perhaps GHash.IO again grows towards 51%. We do fully recognise the concerns and possible threat posed by an entity with malicious intent taking control of enough mining power to exploit the 51% scenario, but we also have confidence and agree with the views expressed by the Bitcoin Foundation that any such exploitation or attack ”would be obvious it was happening, and pretty easy to defend against. The transparent nature of the blockchain provides unprecedented insight for all to investigate and report such behaviours. We also recognise however that a long term preventative solution to the threat of a 51% attack does have to be found, the current situation we find ourselves in (essentially being punished for our success) is damaging not only to us, but to the growth and acceptance of Bitcoin long term, which is something we are all striving for. To that effect we are in the process of arranging contact to the leading mining pools and Bitcoin Foundation to propose a ‘round table’ meeting of the key players with the aim of discussing and negotiating collectively ways to address the decentralisation of mining as an industry. Our aim is to do this quickly with a possible date coinciding with the CoinSummit Conference in London. Do the right thing, the same thing BTC Guild did in 2013, and limit your damn power. Quit trying to pretend you're innovative in any way. You knew going into this game that getting too big was an issue and now you're trying to sidestep your responsibilities. BTW, claiming you want to do a round table meeting and then expecting other pool operators to fly to London to do a CLOSED MEETING about this issue is in no way a solution to the problem. |
|
|
|
All right, WHO ATE ALL the Lucky Charms and put the empty box back in the pantry!  The Lucky Charms box is never empty...it just doesn't have any marshmallows left. |
|
|
|
|
The pool update mentioned previously is now underway, and will likely begin testing early next week. This update will drastically improve the system's ability to add and remove new coin chains on the fly to improve our profits as new coins come and go. It will also implement partial shifting, where some users are moved to one coin while the rest of the users remain on another, to reduce stales caused by very low difficulty coins, but still let the pool gain profit from them.
The update will also remove minimum limits on exchanging your coins hourly, since the system will credit you directly in BTC or LTC (users choice).
More details will be made available during the week now that I'm able to devote my full attention to the rewrite.
|
|
|
|
Sadly 1/2 of that went over my head to be honest, but I will read up on it.
Would there be a way to have software implement a query to make sure the miner will submit a winning solve (like a test solve) every X number of shares. I guess that would require a protocol change since the pool would have to issue the challenge work.
ASICs do not always test every nonce from 1 - 2^32. There's many reasons this may happen such as 1) Many will slice that range into pieces based on the # of chips on the board, giving each one a slice. If a chip is damaged, that range isn't checked. Hardware errors. 2) It may be setup to have modules, with each module getting a range, but some units only have 1 or 2 while others have 8. Instead of splitting the ranges up evenly between available modules, it gives them their static range and ignores the others. 3) It may immediately feed in new work once a solution is found for a nonce range, even though multiple solutions can exist in the full range. Additionally, modern mining protocols have the miner use a local counter inserted into the coinbase in order to generate work (this is why stratum and GBT are immensely more efficient than getwork, they can make their own work locally). That counter will be in a different state for every single miner. If a call were added which forced miners to have that counter in a specific state, you've just clued in a block withholder that the work it received is a test for withholding, so they won't. |
|
|
|
11 blocks in ~5 hrs?  Clearly a block withholding att--err, wait a minute...block producing attack? |
|
|
|
If Eligius is withholding payment to this user (and rightfully so), will he redistribute those 200 BTC to the other members?
And what about here on BTC Guild?
I noticed luck has gone back up. So was it really bad luck before, or was it an attack?
It was bad luck earlier this week. But who knows, maybe yet another user is attacking (it isn't the previous withholders). You can read above for why it's impossible to detect an attack unless it is sustained for long enough time to provide statistical anomalies for users. But the bad luck spike we had lasted only a few days, and was caused by just a few very poor rounds. The pattern does not fit an attack because we'd have a few normal length rounds, then one or two bad rounds, and then back to normal. There weren't any significant speed fluctuations between those changes. Eligius was able to hold 200 BTC hostage because Eligius does not pay out regularly. BTC Guild pays out multiple times per hour. Even if I froze the user's accounts, you'd get maybe a dozen, two dozen coins. In return, you'd end up with some very pissed off people who already know how to weaponize their ASICs against a pool by simply reverting a patch. |
|
|
|
There's a lot of accusations flying around here. Now IIRC the issue was that some big miners did not appear to be pulling their weight in terms of blocks solved against hash power, and this turned out to be a previously undetected flaw in the software which resulted in results not being submitted. After they were suspended and investigated, it seems the error was found and corrected and they are now mining again. If that is actually what happened, then they have not stolen anything. OK, they may have inadvertently diluted everybody's earnings, but that is not theft; one could argue that they were suffering as well by not getting their share of any blocks they should have declared. If I'm wrong (and I really can't be bothered to go back and read all through it again) then I'm sure somebody will put me right.
This is correct. And the problem is, you CANNOT detect it early. It's literally impossible. Just like the pool can have rounds taking 5-8x difficulty worth of shares to solve a block, individual users do as well. This means at current difficulty, you cannot even begin to SUSPECT a user until they have submitted ~60b shares without a solve. And even then, it is absolutely possible that they are unlucky. It only becomes likely something is wrong at the 80-90b share mark (and even that isn't proof, it just means the odds aren't good for simple bad luck). The user that was not submitting blocks IS back on BTC Guild. They have NOT been withholding blocks since their return. There are more than the 2 accounts identified at Eligius involved. Since they have come back, their expected blocks vs submitted blocks has been perfect (1 of the accounts is actually fairly far ahead of expectation). |
|
|
|
Also, it should be noted that the most recent example of this attack was apparently not an attack, rather it was probably a software problem - although this should have already been detected during testing on the testnet, so I'm not sure how "unknown" it could have been.
The problem was their software discarding shares that matched 2^32-1 difficulty or better. Anything UNDER that, they worked fine. So testnet would not have detected anything wrong. |
|
|
|
|
Regarding the hard fork to make block withholding impossible: It will never happen. AFAIK, that hard fork would also break all existing ASICs.
Granted, a hard fork does NOT need 51% mining power to be implemented. What matters with a hard fork is the market (people who accept/trade Bitcoin) moves to the new fork. But unless I'm mistaken, the secret data used to prevent block withholding would be incompatible with all existing mining hardware, which will immediately make such a fork very hard to achieve. It would more likely kill BTC entirely due to the competing standards.
As for variance/luck/withholding: I'm monitoring closely users with bad share/block ratios. Unfortunately, there's really not much else I can do. It was around June 9th we had a pretty big dive. But then we had a decent rise that roughly offset it before going into 3 days of consecutive very poor luck, caused mostly be a few 5 and 6 hour rounds. However, the pool was at 96.8% luck for the last month before the dive, and rising. 99% is "neutral" in the sense of expectation, since you would expect a ~1% orphan rate which means 100% is actually slightly lucky.
The pool has not grown significantly, nor has the difficulty risen in the last 3 days. The current dip appears to be luck, not withholding, based on the fact that the long rounds mean all the prior speed (11-12 PH/s), which was performing right within expectation for most the last month, weren't finding blocks for 5-6 hours along with the new speed that joined.
|
|
|
|
I don't really see how a chip that can calculate SHA-256 hashes would be able to have a flaw like this. AIUI, the ASIC doesn't know about difficulty, it just hashes difficulty 1 shares. ASICs don't actually assemble the block, the pool does that work. The mining software just grabs whatever hashes it finds that are above the share difficulty from the ASIC and submits them to the pool..
Someone with a better understanding of this might be able to correct me but AFAIK, it would have to either work or not work.
In the case of the April-May block withholding, the error, as I was told, was due to the software not the hardware. The software was checking the difficulty of results the hardware returned, and was having an error when the representation of the difficulty was > uint32 for the share, causing it to be discarded even though it was still a valid result. At the *hardware* level, I'm doubtful this is possible without being explicitly designed to do so. ASICs are very dumb, as you pointed out. They should only care about diff >= 1, and report the result back to the software for further checking and submission. |
|
|
|
Yes the value of the coins add very little to today's profits in terms of GAAP accounting, but merged mining does not cost anything to do.
Actually it does. A new block header and template needs to be sent to all clients every time the merged coins have a new block on their network. If this results in even 0.1% more stale shares on your miner, then you've lost money compared to just mining BTC+NMC. If it results in 1% more stales, then you've lost money compared to just mining BTC alone. This. You can circumvent it slightly by not sending out new work for merge-mined chains when those blocks update. However, there is still overhead from running extra coins that will impact pool performance. Another coin daemon means more network communication, very marginally slowing things down. Another coin daemon means more hard drive access and CPU time when a block is found on the other coin. The bottleneck for most pool servers is in the coin daemon, when it is processing new blocks. Even on SSDs and fast processors, it is anywhere from 50-200ms worth of time for bitcoind to return a block template. This would take even longer if another daemon is processing a new block (which would happen if the most recent bitcoin block was also a merge mined block for that coin!), increasing the time it takes for the pool to move to the next block. There is not a single coin aside from Namecoin that actually merits the performance hit of merged mining. It's a small, virtually immeasurable amount of delay added, but the other merge mine coins are so worthless that it's not worth risking losing time on a BTC block. |
|
|
|
Yes I know luck is involved. However that should make payouts smaller not fewer. Correct?
It depends. If your account has a huge balance and you're getting paid hourly until it depletes, it wouldn't change the frequency (though yesterday there was significant hot wallet maintenance that lasted on & off about 8 hours). If the pool luck is bad and you already had your full balance paid out, you would receive fewer new payouts (fewer blocks solved = fewer times your balance increases during the day). Yes yesterday was bad, however and maybe I am just to much of a newb. When you complete a shift about every hour. Then there should be 23 to 24 payout (not to my wallet) but to the btc account. I understand spool up a and spool down. But after two months the number of pay outs, not auto payout should start to equal out. Not running behind. Having said all of that I really like btc guilds easy of use and interface, it is to notch. Jerry You get paid when the block is found. Not when the shift ends. As soon as a block is solved your account is credited instantly. |
|
|
|
Yes I know luck is involved. However that should make payouts smaller not fewer. Correct?
It depends. If your account has a huge balance and you're getting paid hourly until it depletes, it wouldn't change the frequency (though yesterday there was significant hot wallet maintenance that lasted on & off about 8 hours). If the pool luck is bad and you already had your full balance paid out, you would receive fewer new payouts (fewer blocks solved = fewer times your balance increases during the day). |
|
|
|
Is anyone else getting really slow payouts for the shift work from BTC Guild?
I received only 13 payouts in 24 hours, 15 the day before, and only 10 payouts in the last 20 hours....
What is up with this?
Jerry
There is a pretty graph at the bottom of the PPLNS stats page that will clearly show you this. |
|
|
|
When do you think we will get back to a 3 month 100% luck? It's currently just below 90%
99% luck would be "neutral" considering orphans are about a 1% chance. The luck graph does not factor that in. The 3-month luck will likely be back in the upper 90s (or who knows, low 100s if we're lucky) around August 10th. That's (approximately) the point where the impact of the block withholders will no longer be a part of the 3-month average. |
|
|
|
CEX.IO has been working on possible ways of decentralising Bitcoin mining since February. We will present our solutions to the Bitcoin community in the nearest time and ask you for understanding our intentions in the right way.
New slogan: CEX.IO, working on decentralizing Bitcoin mining by controlling one of (almost certainly THE) largest private mining farms on the planet. |
|
|
|
Someone steal all the luck?
(24H / 3D / 1W / 2W / 1M / 3M / All Time): 67.655% / 79.863% / 92.032% / 93.406% / 95.363% / 89.488% / 98.073%
It looks like that. The Eligius-attacker is seems to be attacking BTCGuild at the moment. No, they're not. The "Eligius attacker" is the one that dragged BTC Guild down from April to May 7th. They were a problem for Eligius before that period, and on and off in April - May 7th. They have since fixed their hardware, which all signs point to being a bug they were NOT aware of at the time, based on the communication with them. Within 48 hours of their accounts being frozen in May, they were back and submitting blocks. Since that time, they have been submitting blocks within expectation. Today's luck is the result of 4 poor rounds in relatively quick succession. 2x 4-hour, 1x 5-hour, 1x 3 hour blocks within the same 24 hour period. The other blocks found during the day were roughly neutral (45m - 2h). We just didn't get any quick bursts to offset the long ones. |
|
|
|
I have a theory. The network hashrate has just jumped up 14PH approx as per bitcoinwisdom difficulty.
Perhaps this is a large farm, concerned about rising difficulty and wanting to minimize the impact of difficulty increases. They mine on btcguild/eligius and submit low difficulty shares (for which they are paid) and discard winning shares (so the network hashrate is artificially low). Profit ?
Could they be not discarding winning shares and instead using them in solo mining setup? Guarantee themselves benefits of pooled mining and win some by solo mining winning shares by withholding from a pool? Work done for the pool is useless for solo/any other pool. The hash is only valid for the pool it came from, with the payment to the address the pool told you to put. Otherwise the pool's hash (since the pools check your work) will not match yours and it will be rejected. |
|
|
|
|
Show Posts
