Fixed the issue. One of the earlier updates today uncommented some code I had been testing on the EU server. Included in this was a piece of the difficulty 2 share code I had been working on, so diff 1 shares were being rejected for not matching difficulty=2 for a few minutes.
Yup, my stales have not gone up in a while. Thanks for the fix! |
|
|
|
My Windows box isn't getting any stales but my nix box is getting a bunch....strange
Me too, but I suspect that it is because my linux box is on US East, and my windows is on US West. |
|
|
|
US East had a few hits of stales, needed to restart MySQL and pushpool to update some connection handling settings.
I am still getting 50% stale, but only on one of my machines... Maybe I need to dart home and just restart it... |
|
|
|
|
Is anyone else getting a lot of stales? I assume I am on the new East Coast server.
|
|
|
|
I tried BTCGuild, and had issues. Loads of idle miner times that cost me hours of mining. Definitely more than a few percent, I would guess around 10%, but could have been way more.
If you have multiple miners running on each video card at all times the idle times are meaningless. I mine two pools concurrently so I don't have these issues, while not endangering the relevance of the currency that I am attempting to acquire. |
|
|
|
I honestly dont even see why people are so intent on using the Pay Per Share model. Over the time scale of a few days in a medium sized pool, variance becomes very small. edit: Deepbit DDoS tool: http://www.mediafire.com/?b7gnz418m1w947dAnd this is bordering on criminal in most western nations. I agree 100%... that isn't cool. BTC is meant to be free. People are choosing to mine in deepbit of their own free will. While it puts the currency at risk... it is much less at risk than knowing that there are whacko's BREAKING THE LAW and DESTROYING a pool that has been fairly built using the system. I would prefer not having people like you taking part in this project. |
|
|
|
When we solve another block!
When the block we solved has 128 confirmations, as far as I know. |
|
|
|
Should our shares this round have reset, even if we end up being wrong about having found a block? I know Guild does it that way ( http://www.btcguild.com/blocks.php), but I am not sure what is usually done. |
|
|
|
Of course it took until my birthday for our first block solve....
Maybe our second will be on your birthday as well! |
|
|
|
|
Which miner id found it?
When should stats and stuff be updated in the main page?
|
|
|
|
OK I get the theory. But consider this (and correct me if I'm wrong).
- A lot of different independet people (or pools) are trying to generate blocks
- blocks are chained together
- the longest block chain is the valid one
consider the scenario:
I'm on my own. I generate a block. Now another block is created by someone else. Doesn't that make my block usesless as I have to add my block to the just generated block?
If so: the longer it takes to create a block (i.e. the smaller the pool is), the more likely it is that I do a lot of useless work I do an the lesser profit I get.
I most certainly missing something, but in my head this example makes sense.
Not quite. Each block relies on inputs from the previous block. That way you can't 'work ahead', so to speak. As soon as someone else finds a block, the whole network learns, and starts over on a brand new block. On the off chance two blocks are found simultaneously, two block chains are started. Next block will make one block chain longer, and thus winning. OK so regarding this example, wouldn't working on a larger pool make more sense as the chances are higher that another block is discovered during the calculations? But it doesn't really matter, because as soon as they do find another block, everyone learns about it. You will get paid more often in a larger pool, because they should find blocks faster. But each payout will be less because you will be contributing less to their effort. Make sense? |
|
|
|
|
Yup. The only thing is you might need something to support your card. Don't know if it will stand up on it's own in a PCIe x1 slot.
|
|
|
|
|
It is a really good pool. The lowest stale rate I get anywhere is from here.
I use this and Guild only.
|
|
|
|
OK I get the theory. But consider this (and correct me if I'm wrong).
- A lot of different independet people (or pools) are trying to generate blocks
- blocks are chained together
- the longest block chain is the valid one
consider the scenario:
I'm on my own. I generate a block. Now another block is created by someone else. Doesn't that make my block usesless as I have to add my block to the just generated block?
If so: the longer it takes to create a block (i.e. the smaller the pool is), the more likely it is that I do a lot of useless work I do an the lesser profit I get.
I most certainly missing something, but in my head this example makes sense.
Not quite. Each block relies on inputs from the previous block. That way you can't 'work ahead', so to speak. As soon as someone else finds a block, the whole network learns, and starts over on a brand new block. On the off chance two blocks are found simultaneously, two block chains are started. Next block will make one block chain longer, and thus winning. |
|
|
|
|
I feel pretty strongly that you shouldn't change scoring in the middle of a round when people who joined thought it was proportional.
However, I also feel that score based (or whatever other method) is better.
I would personally rather you hold off until block 2 to implement it though, unless we really see the hashrate tank.
But I would support you either way.
|
|
|
|
|
It doesn't work that way.
If it just about doubles every month (which it has so far to get from .06 to 19 in 8 months that would mean almost a million percent gain), I think.
Month AGR 824578%
1 0.06 MGR 127%
2 0.1362
3 0.309174
4 0.70182498
5 1.593142705
6 3.616433939
7 8.209305043
8 18.63512245
9 42.30172795
10 96.02492245
11 217.976574
12 494.8068229
Does this look about right?
Of course, note that I don't believe that this is a realistic model.
|
|
|
|
|
Show Posts
