Topic: [~1000 GH/sec] BTC Guild - 0% Fee Pool, LP, SSL, Full Precision, and More - page 21. (Read 379078 times)

Seriously, my theory is that whoever made that rule did not understand what an 'invalid block' is.
Because it is 'nothing' - it should not effect the payout - but it does.
Thus clearly misunderstood by whoever decided it should effect the payouts.

It has no effect on the amount of BTC received by the guild.
It has no effect on the share load on the guild.
Mathematically, it SHOULD have no effect on the payout of the guild.

It reduces the payouts for some.
Increases the payouts for others.
AND increases the payouts for the guild.

An example where it has made a difference: block 235891
Some people who worked on that who didn't have 2.5% donation got nothing.
Cause: the previous 'round' was an 'invalid block' and this 'round' was only 7 seconds.
No averaging will correct the lost amounts.

Yes there is a mathematical difference (though that was obvious from the start)

Edit: though I should add that your argument is in agreement with my suggestion that the pool should ignore them: " ... ... ... zero in the long run"

Because it is hard to support that many connections!

I keep wondering why botnet owners are too lazy to setup their own pool, you know you'll get banned eventually.

It's being worked on.  The current testing code takes far too long to run, and I'm worried that the long run time could cause a double payout if somebody tried to get a payout during the script.  I'm working on optimizing how user rewards are stored/accessed so it runs almost instantaneously, that way I can simply lock payouts while the script runs and turn it back on when it exits without inconveniencing too many people.

Banned a brand new botnet that decided to give our pool a test that was hogging resources for long poll connections on US Central.  Also banned a user who was operating between 15 and 20 GH/s but running at 2-3% efficiency.  I'm not fond of somebody requesting 5+ million getworks in a 24 hour period but only sending in ~100k shares, which means he was putting nearly 1 TH/sec worth of load on bitcoind.


Regarding invalid rounds:  Most pools roll them into a new round because they don't offer ANY payment on them.  We do for quite a few users (average payouts on invalid rounds at ~15 BTC).  In a proportional pool, whether the shares are rolled forward has negligible impact on the end reward.  If people were leaving during the invalid round/next round, you get MORE due to the share reset.  If people were joining during the invalid round/next round, get get less due to the share reset.  We're talking about a very short time frame [a few hours if we're unlucky, a few minutes if we're lucky], where the pool speed is not likely to fluctuate much in either direction during that short time span.

The difference is on what a share is. Is it the right to get a payout proportional to the number of shares that were submitted since the last valid block? Or is it the right to get a payout proportional to the number of shares that were submitted since the last block as long as the network deems the next block that the pool thinks it finds is valid.

Mathematically you are correct, assuming no pool hopping, constant hash rates, etc etc.

Seriously?  Your theory is that the guy that created and operates the second largest pool is an idiot?

There is absolutely no mathematical difference between the two choices, in the long run.  This should be self evident, but if you don't believe me, you can check this yourself by looking at the round history and calculating what your payout would have been if each invalid round had been merged with the round after it.  Be sure to look at all of the invalid blocks though, because while you might be up or down a couple of percent on any given round, they will (must!) average out to zero in the long run.

Upon further reflection, you are probably right. The correct thing to do would be to put all of the invalid round's shares into the new round.

The thing that convinced me of this is the case where a small pool gets an invalid. It would be wrong in that case to throw away a weeks worth of work because of that. And if it is wrong in that case, it is wrong in all cases.

2.5% contributors would be double paid for shares, but the pool wouldn't lose any money from this at all.

Hmm I guess the real answer is probably that those who decided didn't really understand what an 'invalid block' was at the time and the decision has stuck

As for programming, it's simple if the actual shares are logged.
I'd expect they are - even pushpool does it (with the block number the share was generated for)
I would be surprised if any system would risk only keeping a numerical count of the shares - since a single record corruption could represent a loss of the total share record of a user for a round and be unrecoverable.

Thus when determining the round it would logically be the count of shares from the block number after the last successful up to the new successful block number
(instead of from the block number after the last successful or the last invalid up to new the successful block number)
Logically the same and most likely just as simple.

Also there would be no need to specially handle the 'invalid block' - possibly just remove it.
Since payout is well after the new block is found - the correction of the found block records (removal of the invalid) would be simple and all that is needed to correct the share calculation (i.e. the invalid block doesn't exist any more - which is shouldn't anyway)
... long ramble - but just pointing out that there is no odd complexity involved ... and a simplicity as well.

I can see it both ways.

From a miner's perspective, in a proportional pool, if he submits a share, he expects to get some (however fractional) payout in theory. If his share was submitted during an invalid block he won't though, through no fault of his own.

From the pools perspective, as soon as bitcoind says 'gratz you got a block' the pool closes the current round, and starts a new one. Only afterwards when bitcoind decide to change it's mind and take back it's initial claim does the pool declare a block invalid.

From a programmatic standpoint it is much easier to count invalid rounds as their own round, since you won't need special logic for it. Just to take the shares away when bitcoind changes its mind.

Looking at it logically, I can see your point though. But still, I don't think it's worth it. In essence, the miner got shares in a block. They were just later taken away. Rolling these shares back into the current round would probably be too much of a hassle. And then, what would you do with the 2.5% people? Count their shares twice???

And we are talking about BTC Guild, the 2nd biggest pool. It isn't like you might waste a week of hashing for an invalid block in a small pool. Maybe a few hours at worst.

Hmm - you haven't actually answered the question in reality.
You've just repeated what I asked as an answer if you look at the details of what you have said.
Since: yes I realise that already, that was the point of my question

The comparison to a solo miner is actually not relevant.
A solo miner gets all the BTC of their effort when they succeed in getting a block 'first' on the network.
If they put a block answer on the network too slowly, this does not effect the % of the BTC they receive next time they succeed in being 'first'

A pool determines to divide up the BTC usually based on the % of the total effort.
The fact that one person submits a possible solution to a block should not invalidate all the work that went before.
There is certainly no logical stand for that - since when a solution is submitted and wins - most of the work that counts for shares has nothing to do with the block that has been won - most of the shares are no different at all to the shares of an invalid block that has occurred directly before the successful block.

No I didn't mean is was bad for the miner, I meant it was bad for the pool's funds.
I'm not trying to lead people astray

You are wright, it "appears to be an illogical decision" ... but is not. Its just a decision based on how bitcoin works.
At present technological level of our society, every information (digital or not) takes time to reach its destination. Its perfectly normal that a block to be "discovered" by two different miners almost at the same time, lets say 10ms one of each other (at 100Mhs in 10ms are calculated 1.000.000 hashes) . The blocks are perfectly valid for the two miners and they publish it. Now the bitcoin clients present in the network start to validate this 2 blocks. At this point is only the luck that matters because the winner block will be the block that gets faster validations (it can be the second published block that wins if "near" him are more bitcoin clients present that validate it).
So, luck being intrinsic to the validation of block a decision must be taken, and every pool made a decision.
Keep in mind that if you were a solo miner you have been lost all the work ... in fact some pools don't pay for invalid blocks.
You are misled ... they are not payed from the work of other miner done in another block ... "pool's funds" means btc donated ... (mostly from the ones who donate 2.5%) so it seems a correct decision to give to them something back when we get unlucky.
Ciao.

That's an interesting question.

Curious about the "Invalid" block rule.

Since it isn't actually an invalid block, rather a case of some other pool/person getting their block into the network before the pool software does - and the pool not getting the update quick enough before sending out the "late" block.
(correct me if I'm wrong about this: but I'd expect the pool to actually verify the block before posting it ... so it wouldn't actually be 'invalid' in the normal meaning of the word 'invalid' - only 'late')

So basically because of something out of the control of the miners, they get penalised by losing their shares if they don't pay 2.5% donation.
And worse, you also pay extra BTC for the shares of those that do donate 2.5% from the pool's funds.

If treated as normal shares, they should simply continue to count against the block that is finally won,
exactly like all other shares before the successful block already do - i.e. most shares are not from the block that wins but rather from all the blocks since the last block that won.

So ... is there a logical reason for what appears to be an illogical decision to not continue counting all shares until a block gets into the network successfully?

Its not. If you want to buy you should sell your miners. But as long as you keep the miners and spect the price to go up in the future you should keep mining. Keeping the mining but not mine is the worse option. One should either sell them or mine, but not keep them idle.


That is a good decision. I didnt imagine the price of electricity in California was that bad, specially when other parts have it a lot better. Here in Europe is bad, but its more similar everywhere.

I'm in the Dallas/Fort Worth area, and I just saw a notice from one of my Phoenix miners (backup mining thread that was connected to uscentral) that I have never seen before,

it said something along the lines of "server gave work from a previous block, ignoring" or something similar... I just closed the backup miner and let the USWest thread have all 400 MH/s (the USCentral thread also had a higher percentage of stales)

Level3 in LA and Dallas are showing some packet loss on traceroutes to the server, which is causing a few idles for people who connect through those nodes.  Hopefully it will clear up shortly.

Just for the record, thats bad advice .  If the current price means mining is a loss, it would be 100% stupid to continue mining.  It would be smarter to spend the money buying coins and leaving the miners off, since I'd be getting more coins for less USD.

I sold off a large chunk of my miners a few weeks ago because I knew that this state would be one of the first places to become unprofitable.  I sold early before the mass hardware sales began .  Now I'm just running enough to make sure the pool is still running.

The drop started after the MyBitcoin.com and the polish exchange fiascos.

Whether is just panic or loss of confidence or MyBitcoin.com scammers selling the stolen bitcoins is just anyones guess. It could be a combination of both. But we have seen massive sellouts (25.000 bitcoins) in just moments during these last days.


Are you serious? 40 cents? And I though Europe was bad. Thats insane, no wonder why California is tanking and the industry is leaving.

Btw, I know you are taking a conservative position, wait and see, but if you believe bitcoins will rise in price you should keep mining if you have the funds to pay the electricity, because it does not matter the price they have now if you believe it will go up in the future. And if you belive they wont, you should sell the equipent right now to recover part of the money. The wait and see attitude might seem like a middle point, but in reality you have your investment without producing anything, Ive always though that its better to take your guess and use it or sell it.

On second thoughs, Im happy difficulty is going down, so hey, scratch what I said and everybody stop your miners right now!

Just impacted in my personal mining.  You'll notice User ID 1 (me) has almost vanished off the block rewards list.  I'm now just using 2 5870s to mine, at a loss.  California at top tier usage (my house AC alone puts me in top tier basically) is 40 cents/kwh, which is a loss before counting the cost of extra cooling.

The pool still operates at a profit, mostly thanks to the Google AdSense for people under 0.5% donations.


It's also throwing a wrench into my plan to offer some very good VPS servers at even BTC intervals.  Was planning on a ~$12 / 24 / 36 per month (or 1 / 2 / 3 BTC) set of VPS servers, with the BTC price only adjusted when the value went below 10 or above 15, with integrated billing with BTC Guild so you could automatically have your miners pay off your servers each month.