[~1000 GH/sec] BTC Guild - 0% Fee Pool, LP, SSL, Full Precision, and More

[kano]

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?

[1714034514]

1714034514

[1714034514]

1714034514

[PcChip]

That's an interesting question.

[TheMalon]

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?

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.

And worse, you also pay extra BTC for the shares of those that do donate 2.5% from the pool's funds.

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.

[kano]

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?

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.

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.

And worse, you also pay extra BTC for the shares of those that do donate 2.5% from the pool's funds.

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.

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

[sirky]

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.

[kano]

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.

[sirky]

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.

[kjj]

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

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.

[sirky]

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

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.

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.

[eleuthria]

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.

[eleuthria]

"1.5% (Not yet implemented) - Automatic payouts.  User is allowed to pick either a daily time to receive payout, or a specific amount."

Looking forward to seeing this added, what time frame can I expect before this feature is working?

Bringing this back up...

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.

[Nicksasa]

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.

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

[sirky]

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.

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

Because it is hard to support that many connections!

[kano]

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

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.

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"

[cyberlync]

My miners were on BTCguild as backup for some time, but when I check on the website now, there is nothing next to  "Estimated "Rewards" "Unconfirmed Rewards" and nothing next to "24 Hour Rewards". It's as if it never occured... I was checking the site while my miners were on backup (btcguild) and the site showed estimated/24 hour rewards as usual.

[kjj]

My miners were on BTCguild as backup for some time, but when I check on the website now, there is nothing next to  "Estimated "Rewards" "Unconfirmed Rewards" and nothing next to "24 Hour Rewards". It's as if it never occured... I was checking the site while my miners were on backup (btcguild) and the site showed estimated/24 hour rewards as usual.

How long ago was it?

Estimated rewards applies to the current round.  Unconfirmed rewards applies to rounds in the previous 120 blocks.  24 Hour Rewards applies to the previous 24 hours.

[cyberlync]

My miners were on BTCguild as backup for some time, but when I check on the website now, there is nothing next to  "Estimated "Rewards" "Unconfirmed Rewards" and nothing next to "24 Hour Rewards". It's as if it never occured... I was checking the site while my miners were on backup (btcguild) and the site showed estimated/24 hour rewards as usual.

How long ago was it?

Estimated rewards applies to the current round.  Unconfirmed rewards applies to rounds in the previous 120 blocks.  24 Hour Rewards applies to the previous 24 hours.

Umm, it was around the time I wrote the message, not more than half an hour prior to that. So there should be something in Unconfirmed and 24 Hour rewards.

[eleuthria]

My miners were on BTCguild as backup for some time, but when I check on the website now, there is nothing next to  "Estimated "Rewards" "Unconfirmed Rewards" and nothing next to "24 Hour Rewards". It's as if it never occured... I was checking the site while my miners were on backup (btcguild) and the site showed estimated/24 hour rewards as usual.

Estimated Rewards are calculated by your current mining speed (15 minute average) vs total pool speed, rather than shares in the round vs total, to stop pool hopping.

The round you were mining in is still going if it was that recent, so your estimated has dropped to 0 since your speed is currently 0.  Since the round hasn't ended [or it hasn't been announced due to the 1 hour delay], your unconfirmed hasn't gone up yet.

[cyberlync]

My miners were on BTCguild as backup for some time, but when I check on the website now, there is nothing next to  "Estimated "Rewards" "Unconfirmed Rewards" and nothing next to "24 Hour Rewards". It's as if it never occured... I was checking the site while my miners were on backup (btcguild) and the site showed estimated/24 hour rewards as usual.

Estimated Rewards are calculated by your current mining speed (15 minute average) vs total pool speed, rather than shares in the round vs total, to stop pool hopping.

The round you were mining in is still going if it was that recent, so your estimated has dropped to 0 since your speed is currently 0.  Since the round hasn't ended [or it hasn't been announced due to the 1 hour delay], your unconfirmed hasn't gone up yet.

Makes perfect sense. Thank you for the fast reply!!!

[kjj]

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"

Let me try this again.

For people that don't donate at least 2.5%, there is no difference (in the long run).  For people that do donate at least that much, and for the pool itself, there is a difference.  A huge difference.

As to your idea that he doesn't know what it means, that is obviously incorrect, which is very easy to demonstrate:  The biggest part of the incentive structure of this free pool is built around that difference.