|
Whoever owns 1CfsAiYaVfk12dnZpZALcRSP9jjWDk26FX - Your software is terribly broken and paying out massive transaction fees. Over 100 BTC in the last 24 hours as best I can estimate, and a lot of it is going to pools that pay transaction fees to miners meaning there isn't an option to just ask for the money to be sent back.
|
|
|
|
I had not noticed it was one week ,thank you eleuthria ,maybe I can find a longer history .
Thank you Dr Haribo for the link but there are only couple posts discussing the merits of pools .
What I was referring to was that even though BTC Guild has the most Blocks discovered does not instantly mean it is the preferred choice for a small new miner .
I suspect a lot of new miners think big is better and of course that could have been the case .
My findings suggest that,
Slush's pool over the 100 blocks found took 580 ghs of power per block .
While:
BTC pool over the 465 blocks found took 619 ghs of power per block.
When your pool find a block my share of the block would acoount for a larger percentage of the reward .
It was surprising to find the largest pool equal to some of the smallest pools in hashing power required to reveal a block exactly 617 ghs that was not expected by me.
The top pool BTC has 5 times the power of Slush's yet produce 4.5 times the blocks .
So it seems based on the graphs provided 1gh works more efficiently in slush's pool than any of the competition so far .
Obviously history is not the best forecasting tool but it is all we have as far as I can tell .
It would be interesting to find out what all the 617ghs groups have in common since blocks are said to be a lottery the hash rate to find them seems to have some common ground .
What you're observing is variance. It has nothing to do with pool efficiency, and it is not something that can predict the future. Trying to pick a pool based on past luck is simply not understanding how mining works. The reason BTC Guild is preferred by a lot of miners (outside of interface/stability) is that it's so large that even when luck is TERRIBLE, you're getting paid dozens of times per day. It's many small payments happening constantly rather than large payments happening irregularly. Right now we're having a very bad round. It's been 2 hours since our last block. For many pools, a 2 hour block is the normal rate. On any other non-PPS pool, this is equivalent to a roughly 12 hour round (or longer), but the pool is so fast it gets finished much quicker. |
|
|
|
This is the information I was basing my research on :- https://bitcointalk.org/index.php?topic=104664.0I assumed it was over a long period of time since one pool alone had 465 blocks . My hash rate is only 400mghs yet lol . Still cannot figure out how to get an asicminer working 1 week is not a long period of time. Even 1 month isn't sufficient for most pools to even out on variance. |
|
|
|
I just wish that BTCGuild can shut down their getwork to reduce some hashrates. Its bad for bitcoin economy.
Getwork dies on BTC Guild on October 14th. But it won't make much impact, it's currently ~1% of the total pool hashrate. |
|
|
|
Beware of implying something that is indeed incorrect ...
The unlock is of course either an interface in a system that you wrote that can of course be bypassed ... or a button that you click on when you believe a pool member has provided your required amount of proof.
It is indeed NOT true to say "can only be removed by signing a message"
It would be true to say that you "eleuthria" will bypass the rule when someone signs such a message.
Fine: It can only be removed by somebody who has direct access to the database server because the permissions to remove that lock can only be executed when logged in from 127.0.0.1 (no remote DB connection can delete the lock record), on a server which can only be accessed via a specific VPN or local console access because it has no public IP to connect into. |
|
|
|
Has difficulty ever adjusted down? And if so, when was the last time it happened
Mid-late 2012 it had some drops when the price was on a continued decline. |
|
|
|
|
Just a friendly reminder: Do not use the same username/password combination between sites, and especially don't reuse the same password on your email address. BTC Guild along with many other Bitcoin related services are always being targeted for account breakins. In the last month, BTC Guild has placed IP bans on over 2 million different legit IPs (not forged) that have been used for trying to scan accounts for reused passwords from various leaked databases from other sources.
Additionally, you can be sure your balance is always safe by enabling the wallet lock feature. This is permanent and can only be removed by signing a message using the private key of that wallet to prove you own it (meaning it shouldn't be used unless you are running your own bitcoin wallet locally). No amount of begging and "other proof" of account ownership can be used to override a wallet lock, making it the strongest protection you can possibly enable for your pool balance.
|
|
|
|
That's really strange - there are lots of us out here running cgminer 3.1.1 and BEs. No indication of any problem in cgminer? Is there sufficient power available at your hub? Does the problem go away if you run, say, just 6 or just 4 of them at a time instead of 8?
It seems to have stopped...now the rejects have stopped accruing... Sorry this seemed to get missed in terms of a reply. Other currently refers to one of two types of reject: 1) Lowdifficulty - Your miner was submitting work at a difficulty that was lower than what the pool told you to mine at. 2) Unknown work - Your miner was submitting work that didn't correspond to work that was sent to you from the pool. Unknown work is sometimes related to a bug in cgminer (which I believe has been fixed) where the extranonce field would not have proper padding or would be sending non-hex characters. Lowdifficulty should only happen briefly (if at all) when your difficulty is increased by the pool. There was a bug in the Stratum Proxy from slush that was causing lowdifficulty errors to happen frequently, but I added a workaround on the pool to prevent that. |
|
|
|
I've lost track and am confused, did he say he has silver and blue erupters on hand or coming in? I don't want to order before he has them and end up with black or red ones.  All inventory is blue/silver right now. No red/black could possibly sneak in. |
|
|
|
A number of years ago your pool delivered earning of something like 40% of expectations for months. A number of people were convinced that you were a thief because of it (that something was subtly broken, or there was some witholding attack seems like a more likely explanation, in my view), but that hasn't inhibited you from having the largest pool by far.
Actually, it was only about a _5%_ difference. Vladmir sucked at math and had no idea how to do a proper statistical analysis (he was using binomial distribution), and was trying to launch a competing pool so he was slandering the largest pool that didn't charge a fee at the time. EDIT: I think in the end his claim was BTC Guild was "stealing" 4% of the total mined. This was the difference between 100% neutral expected revenue and the actual revenue. |
|
|
|
33% of the hashpower will successfully reverse 6 confirmations 21% of the times it attempts. 33% can successfully reverse 2 confirms 53% of the times it attempts. "51%" isn't a magical number. Large consolidations of control over hashpower undermine the security assumptions behind Bitcoin, Satoshi was opposed to centralized pooling, for good reasons— but sadly his vision didn't see quite far enough to offer the alternatives. I don't think it's fair to single out BTCGuild here— though it is the largest pool— because you could get to the same number through combinations of compromising a couple of the smaller ones, which for all any of you know could already be run by the same parties. These numbers are true, there is one thing to keep in mind: Any attempt to do so *is* visible to miners. The second a pool tries to start a fork and reverse a transaction, miners can see the prevblockhash on the pool no longer matches the main bitcoin network. While this isn't unusual in the case of an orphan race, the only time it has ever happened for more than 2 blocks in a row that I can recall was when we had a hardfork starting. Additionally, an unsuccessful attempt would be completely apparent to miner's because their earnings would plummet [unless the pool continued to pay miners for the fork blocks]. Since BTC Guild's earnings can be audited down to the block hashes that generated payouts, this would be obviously false due to the blocks that were paid not existing on the blockchain. BTC Guild is gaining on % of the network again, and I've stated in the past I think this is something that will always happen. A zero-sum method of earning Bitcoins will always lead to natural monopolies as people prefer to get a steady income over a lottery. There is one big change coming up though that will probably prevent any single entity from becoming 51% again, and that is the emergence of private mining companies. We already have ASICMINER and GHAsh.io, which have effectively taken 25% of the network for themselves that no pool will ever be able to take. There are other similar companies coming online as well, which will take another chunk of the available network hash rate. Being private entities, this is somewhat riskier (the power of a pool can easily be removed by it's members), but they will all be competing against each other in order to keep their slice of the network. |
|
|
|
eleuthria, why during the shifts in last several days, I get 20% lower submitted shares in PPLNS stats, but the chart showed almost constant hash rate?
If the pool speed is higher, you will have fewer shares per shift (shifts are based on total shares submitted to the pool, not a specific time limit). The N value generally increases when shifts get too fast, so once in a while you'll notice you start submitting far more shares per shift, and then it will likely slowly decrease as the pool continues to grow. Yes, I noticed that my submitted share used to shrink slowly when the pool hash rate was constantly growing, but there was a sudden rise by 20% between two shifts: 2013-09-15 02:30:22 AM and 2013-09-15 03:16:41 AM, and the submitted share are 20% higher since then, is this a result of difficulty adjustment? Yes, the N value was increased when the difficulty went up, in order to keep shifts roughly equal to 2x difficulty. The pool speed is high enough to keep that N value under 1 hour per shift. I try to keep the 'N' set so that a shift is always more than 30 minutes, less than 1 hour, and if possible, keep 'N' very close to 2x difficulty, in order to keep per-shift variance low. While this doesn't really affect miners earnings over a 24 hour period, it helps the psychological effect. People see a shift end with a very low payout and freak out, even if the flip side is a shift could end just as far in the other direction. By using very large shift values (which is possible due to how large BTC Guild is), it helps keep the earnings per shift closer to expectations. |
|
|
|
I see they added basically unlimited USB Erupter "coupons" on the store. I noticed that the shipped price for the coupon units is a whopping .01 btc less than the regular price units. LOL
I guess a .01 saved is a .01 earned...
The shipping price on coupons is for the entire order, not per unit. So yes, if you only use 1 coupon, it's only saving 0.01 BTC. But each unit ordered after that doesn't add to shipping cost. |
|
|
|
Anyone know where this power is coming from? BTC Guild and Eligius are pretty much unchanged from yesterday.
Network hash rate estimates are based on block solve times, which are heavily influenced by luck (variance). For the last 20 hours, BTC Guild has been running at 140~170% luck, meaning the network hash rate estimates are being inflated by ~175 TH/s just from BTC Guild's luck. |
|
|
|
eleuthria, why during the shifts in last several days, I get 20% lower submitted shares in PPLNS stats, but the chart showed almost constant hash rate?
If the pool speed is higher, you will have fewer shares per shift (shifts are based on total shares submitted to the pool, not a specific time limit). The N value generally increases when shifts get too fast, so once in a while you'll notice you start submitting far more shares per shift, and then it will likely slowly decrease as the pool continues to grow. |
|
|
|
I guess I'm just sad because at 2.5 GH/s I can make .02 BTC a day on Slush's pool assuming that we can get a block. The pps plan and the pplns plan on btcguild make it not worth my time because of all the users and 350 TH/s has rate...that's why I need to use a smaller pool...but in doing so I don't get the option of getting as many blocks, although I guess if I look at, I probably would get the same amount either way.
If I get .001 BTC per block from slush's pool (no matter how many hours it takes to find a block) or if I get .000003 BTC every block from BTC Guild and they find 1000x as many blocks a day then it evens out...
*Note, I know my math is wrong, it's merely an explanatory tool...
This is really the entire concept behind pooled mining. Solo mining is a huge payout but extremely rare. Small pool mining is larger payouts but uncommon. Large pool mining is smaller payouts but constant. In the end they all end up roughly the same (solo mining being the absolute best but also the biggest gamble). |
|
|
|
I've been told Anker is very good with honoring the warranty when it comes to failed power supplies. |
|
|
|
As I'm speaking BTCGuild has 43 percent od the network. This is not healthy for the Bitcoin ecosystem at all. Please don't mine there
33% of network hash rate: http://blockorigin.pfoe.be/top.phpUsing a 24 hour graph from blockchain.info is completely useless. BTC Guild's luck has been +50% for the last 16 hours, completely skewing blockchain.info's 24 hour charts. |
|
|
|
Hi Friedcat,
I bought several things of asicminer to an user on ebay called ufoman2002, i think he is an excellent seller, maybe you know him.
In the things that i bought to this user, there is a Blade.
At the beginning the blade works just fine (a week ago), but now i’m getting this message:
Chip: OOOOOOOOOOOOOxOOOOOOOOOOxxxxOOOO
I was running the blade without overclocking and suddenly the hashrate become down to 9.1ghash/s and I saw the “x”s.
I did my research, i tried several things (adjusting voltage, changing clock, changing power supply, etc, etc) but I always get this five x. To compensate the losing of hashing power i overclocked the blade I’m now I’m getting 10.5 ghash/s with overclock.
Because I'm a newbie on this forum, i cannot contact direct to you, so Michael from btcguild.com it's helping me to contact you and i very grateful to him for what he is doing.
Coming back to the original topic, what do you think I should do with the blade?
Thank you and sorry for my english!! I’m from Argentina.
This user is having an issue related to the OOOOxOOO part on his Block Erupter blade interface and is trying to find out if there is anything he can do. Since he's locked in the newbie forum, he can't post here where he would be most likely to get support, so I am cross-posting it for him. The original thread is here: https://bitcointalk.org/index.php?topic=294705.msg3159488#msg3159488 |
|
|
|
|
Show Posts
