Topic: Eligius: 0% Fee BTC, 105% PPS NMC, No registration, CPPSRB - page 236. (Read 1061843 times)

I didn't count in current block, very unlucky one, and there were two very lucky blocks: 2114,00% and 1240,20%.
From 2014-mar-16 13:46:29
To 2014-mar-17 13:19:57
28 blocks found
00:50:29 average time

That 50:29 is better than average, but nowhere near 300%. Are you sure you're not just averaging the luck % numbers? You can't do that.

Ah, I did just that.
After reading all that replies, I now know I can not do that.
I was suspicious on 300%, because 50:29 was better than average, but not 300%.

Quote from: BuildTheFuture on March 17, 2014, 07:57:15 PM

just the timestamps for the first block and the last block, and the number of blocks in between.

Thanks for that.

davebodger

full member

Activity: 154

Merit: 100

So I looked at my NMC deposit address, and the last deposit I got from Eligius was on 2014-03-08. Is this the same as everyone else?

Mine is similar at 2014-03-09.
WK has already said he is working on this and we will get a big payment once he is done.
No worries here.

mdude77

legendary

Activity: 1540

Merit: 1001

Quote from: baddw on March 17, 2014, 09:00:13 PM

Quote from: mdude77 on March 17, 2014, 08:45:19 PM

Quote from: mdude77 on March 17, 2014, 08:27:29 PM

Quote from: mdude77 on March 17, 2014, 08:45:19 PM

Is that because each luck % is "weighted", so 200% has more weight that 101% does?

M

In a way, yes, it's weighted, but just due to the way that numbers work when you take the average of a percentage like this, and the way the luck percentage is calculated. Take a look at an example.

Let's say that the average block find time should be 1 hour, just to make the numbers easier.

BLOCK 1: 1.0 hour (100% luck)
BLOCK 2: 0.5 hour (200% luck)
BLOCK 3: 1.5 hour (66% luck)

Now, if you add 100% + 200% + 66%, you get 366%. Divide by 3 blocks and you get 122%. But if you look at the whole series of blocks, there were 3 blocks found in 3 hours, which is 100% luck.

If you want to find luck for a large number of blocks, it's really easy. You don't have to look at the timestamps or luck for each block in between; just the timestamps for the first block and the last block, and the number of blocks in between.

Of course, this assumes that the expected 100% luck remains constant; i.e., that the network hashrate and the pool hashrate both remain constant (relative to each other; if they both increase by 10%, the expected luck should remain the same). Which of course, is not the case, but for short periods (like 24 hours or less) it is probably a safe approximation.

I follow example #1, but I don't follow the part about "just the timestamps for the first block and the last block, and the number of blocks in between". Can you give an example for that?

M

I think I get it. With your example above, 3 blocks, 3 hours apart, therefore 1 block an hour (which is the target), so 100%.

M

Exactly.

And the target of 1 hour comes from something like "Bitcoin blocks are mined 6 per hour on average; our hashrate is 1/6 of the total network hashrate; therefore we expect 1 block every hour". Of course blocks are mined somewhat more than 6 per hour, depending on how long since the last difficulty adjustment, and how much network hashrate has been added in the interim; and the overall network hashrate and pool hashrate will both vary as well. So the 1 hour is a moving target, constantly changing. But again, it should stay "fairly" constant over a short time period.

If I could boil it down, I would probably choose to show something like an EMA(24h) for Luck at the top of the main Eligius site, instead of a current block luck %.

I think I'm in over my head.

Thanks.

M

baddw

hero member

Activity: 700

Merit: 500

Quote from: mdude77 on March 17, 2014, 08:27:29 PM

Quote from: mdude77 on March 17, 2014, 08:27:29 PM

Is that because each luck % is "weighted", so 200% has more weight that 101% does?

M

In a way, yes, it's weighted, but just due to the way that numbers work when you take the average of a percentage like this, and the way the luck percentage is calculated. Take a look at an example.

Let's say that the average block find time should be 1 hour, just to make the numbers easier.

BLOCK 1: 1.0 hour (100% luck)
BLOCK 2: 0.5 hour (200% luck)
BLOCK 3: 1.5 hour (66% luck)

Now, if you add 100% + 200% + 66%, you get 366%. Divide by 3 blocks and you get 122%. But if you look at the whole series of blocks, there were 3 blocks found in 3 hours, which is 100% luck.

If you want to find luck for a large number of blocks, it's really easy. You don't have to look at the timestamps or luck for each block in between; just the timestamps for the first block and the last block, and the number of blocks in between.

Of course, this assumes that the expected 100% luck remains constant; i.e., that the network hashrate and the pool hashrate both remain constant (relative to each other; if they both increase by 10%, the expected luck should remain the same). Which of course, is not the case, but for short periods (like 24 hours or less) it is probably a safe approximation.

I follow example #1, but I don't follow the part about "just the timestamps for the first block and the last block, and the number of blocks in between". Can you give an example for that?

M

I think I get it. With your example above, 3 blocks, 3 hours apart, therefore 1 block an hour (which is the target), so 100%.

M

Exactly.

And the target of 1 hour comes from something like "Bitcoin blocks are mined 6 per hour on average; our hashrate is 1/6 of the total network hashrate; therefore we expect 1 block every hour". Of course blocks are mined somewhat more than 6 per hour, depending on how long since the last difficulty adjustment, and how much network hashrate has been added in the interim; and the overall network hashrate and pool hashrate will both vary as well. So the 1 hour is a moving target, constantly changing. But again, it should stay "fairly" constant over a short time period.

If I could boil it down, I would probably choose to show something like an EMA(24h) for Luck at the top of the main Eligius site, instead of a current block luck %.

mdude77

legendary

Activity: 1540

Merit: 1001

Is that because each luck % is "weighted", so 200% has more weight that 101% does?

M

In a way, yes, it's weighted, but just due to the way that numbers work when you take the average of a percentage like this, and the way the luck percentage is calculated. Take a look at an example.

Let's say that the average block find time should be 1 hour, just to make the numbers easier.

BLOCK 1: 1.0 hour (100% luck)
BLOCK 2: 0.5 hour (200% luck)
BLOCK 3: 1.5 hour (66% luck)

Now, if you add 100% + 200% + 66%, you get 366%. Divide by 3 blocks and you get 122%. But if you look at the whole series of blocks, there were 3 blocks found in 3 hours, which is 100% luck.

If you want to find luck for a large number of blocks, it's really easy. You don't have to look at the timestamps or luck for each block in between; just the timestamps for the first block and the last block, and the number of blocks in between.

Of course, this assumes that the expected 100% luck remains constant; i.e., that the network hashrate and the pool hashrate both remain constant (relative to each other; if they both increase by 10%, the expected luck should remain the same). Which of course, is not the case, but for short periods (like 24 hours or less) it is probably a safe approximation.

I follow example #1, but I don't follow the part about "just the timestamps for the first block and the last block, and the number of blocks in between". Can you give an example for that?

M

I think I get it. With your example above, 3 blocks, 3 hours apart, therefore 1 block an hour (which is the target), so 100%.

M

roy7

sr. member

Activity: 434

Merit: 250

It would be better to remove the Luck % column completely and show a CDF % column instead.

mdude77

legendary

Activity: 1540

Merit: 1001

Is that because each luck % is "weighted", so 200% has more weight that 101% does?

M

In a way, yes, it's weighted, but just due to the way that numbers work when you take the average of a percentage like this, and the way the luck percentage is calculated. Take a look at an example.

Let's say that the average block find time should be 1 hour, just to make the numbers easier.

BLOCK 1: 1.0 hour (100% luck)
BLOCK 2: 0.5 hour (200% luck)
BLOCK 3: 1.5 hour (66% luck)

Now, if you add 100% + 200% + 66%, you get 366%. Divide by 3 blocks and you get 122%. But if you look at the whole series of blocks, there were 3 blocks found in 3 hours, which is 100% luck.

If you want to find luck for a large number of blocks, it's really easy. You don't have to look at the timestamps or luck for each block in between; just the timestamps for the first block and the last block, and the number of blocks in between.

Of course, this assumes that the expected 100% luck remains constant; i.e., that the network hashrate and the pool hashrate both remain constant (relative to each other; if they both increase by 10%, the expected luck should remain the same). Which of course, is not the case, but for short periods (like 24 hours or less) it is probably a safe approximation.

I follow example #1, but I don't follow the part about "just the timestamps for the first block and the last block, and the number of blocks in between". Can you give an example for that?

M

BuildTheFuture

full member

Activity: 195

Merit: 100

So I looked at my NMC deposit address, and the last deposit I got from Eligius was on 2014-03-08. Is this the same as everyone else?

baddw

hero member

Activity: 700

Merit: 500

Quote from: MrTeal on March 17, 2014, 06:20:47 PM

Quote from: MrTeal on March 17, 2014, 06:20:47 PM

Out of curiosity, I calculated average luck on Eligius last 24 hours to be 323%!
I extracted that from 'blocks' stats page. Is there some graph picturing this? Or API to use for importing data?

Something seems wrong with that number.

Here's the info on the API:
http://eligius.st/~gateway/pool-apis

I'm in the process of integrating the luck API in my MPoolMonitor app.

M

Thanks.
I didn't count in current block, very unlucky one, and there were two very lucky blocks: 2114,00% and 1240,20%.
From 2014-mar-16 13:46:29
To 2014-mar-17 13:19:57
28 blocks found
00:50:29 average time

That 50:29 is better than average, but nowhere near 300%. Are you sure you're not just averaging the luck % numbers? You can't do that.

Is that because each luck % is "weighted", so 200% has more weight that 101% does?

M

In a way, yes, it's weighted, but just due to the way that numbers work when you take the average of a percentage like this, and the way the luck percentage is calculated. Take a look at an example.

Let's say that the average block find time should be 1 hour, just to make the numbers easier.

BLOCK 1: 1.0 hour (100% luck)
BLOCK 2: 0.5 hour (200% luck)
BLOCK 3: 1.5 hour (66% luck)

Now, if you add 100% + 200% + 66%, you get 366%. Divide by 3 blocks and you get 122%. But if you look at the whole series of blocks, there were 3 blocks found in 3 hours, which is 100% luck.

If you want to find luck for a large number of blocks, it's really easy. You don't have to look at the timestamps or luck for each block in between; just the timestamps for the first block and the last block, and the number of blocks in between.

Of course, this assumes that the expected 100% luck remains constant; i.e., that the network hashrate and the pool hashrate both remain constant (relative to each other; if they both increase by 10%, the expected luck should remain the same). Which of course, is not the case, but for short periods (like 24 hours or less) it is probably a safe approximation.

mdude77

legendary

Activity: 1540

Merit: 1001

Out of curiosity, I calculated average luck on Eligius last 24 hours to be 323%!
I extracted that from 'blocks' stats page. Is there some graph picturing this? Or API to use for importing data?

Something seems wrong with that number.

Here's the info on the API:
http://eligius.st/~gateway/pool-apis

I'm in the process of integrating the luck API in my MPoolMonitor app.

M

Thanks.
I didn't count in current block, very unlucky one, and there were two very lucky blocks: 2114,00% and 1240,20%.
From 2014-mar-16 13:46:29
To 2014-mar-17 13:19:57
28 blocks found
00:50:29 average time

That 50:29 is better than average, but nowhere near 300%. Are you sure you're not just averaging the luck % numbers? You can't do that.

Is that because each luck % is "weighted", so 200% has more weight that 101% does?

M

MrTeal

legendary

Activity: 1274

Merit: 1004

Out of curiosity, I calculated average luck on Eligius last 24 hours to be 323%!
I extracted that from 'blocks' stats page. Is there some graph picturing this? Or API to use for importing data?

Something seems wrong with that number.

Here's the info on the API:
http://eligius.st/~gateway/pool-apis

I'm in the process of integrating the luck API in my MPoolMonitor app.

M

Thanks.
I didn't count in current block, very unlucky one, and there were two very lucky blocks: 2114,00% and 1240,20%.
From 2014-mar-16 13:46:29
To 2014-mar-17 13:19:57
28 blocks found
00:50:29 average time

That 50:29 is better than average, but nowhere near 300%. Are you sure you're not just averaging the luck % numbers? You can't do that.

redvette

newbie

Activity: 2

Merit: 0

IHi,

Looks like I am loosing hash rate with low difficulty shares.
Is it possible to set the workers minimum difficulty?

thanks,

ujka

hero member

Activity: 630

Merit: 500

Out of curiosity, I calculated average luck on Eligius last 24 hours to be 323%!
I extracted that from 'blocks' stats page. Is there some graph picturing this? Or API to use for importing data?

Something seems wrong with that number.

Here's the info on the API:
http://eligius.st/~gateway/pool-apis

I'm in the process of integrating the luck API in my MPoolMonitor app.

M

Thanks.
I didn't count in current block, very unlucky one, and there were two very lucky blocks: 2114,00% and 1240,20%.
From 2014-mar-16 13:46:29
To 2014-mar-17 13:19:57
28 blocks found
00:50:29 average time

mdude77

legendary

Activity: 1540

Merit: 1001