Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool - page 179. (Read 2591920 times)

The correct and direct definition of luck (where >100% is good luck and less than 100% is bad luck) is simply DifficultyExpected/DifficultySubmitted

I'm not sure I understand how you would calculate this, wouldn't the submitted diff for a valid block always be greater than or equal to the expected diff ?

We use the average of the stored hashrate since the last block was found by the pool (and we weight and average the difficulty if it changed since last block found) to determine an average expected time to block, then compare that to the actual time for the block in question.

If the the times are equal its 100%

If we found it faster > than 100%

If we found it slower < than 100%

He's referring to the actual number of shares submitted vs the expected shares submitted to find a block. Since p2pool has no real knowledge of any miner's actual hash rate and submitted shares like ckpool does, the best we could do with p2pool is to evaluate how many share-chain shares we'd expect it to take to find a block vs how many share-chain shares were actually submitted to find it.

The problem is the number of expected shares is constantly changing on p2pool because the share difficulty constantly changes, unlike the BTC network where it's static for 2016 blocks. The best you're ever going to get is just an approximation of luck using the expected vs actual figures, so I see no real reason to change the calculations you're currently using, since they're providing an approximation as well.

DifficultyExpected = 47589591153.62500763
It only changes once every 2016 blocks ...... so yes you know what it is.
The shares in the sharechain submitted have a difficulty pow requirement for each share accepted ... that's why it's accepted.
Sum up the sharechain difficulties (pow requirement, not the actual share difficulty of course) to get DifficultySubmitted.
Yeah as I said, you have those numbers.

Those numbers are how p2pool determines the pool hash rate, except it's not very accurate, and you are using that hash rate number to show the luck ...
Look at the pool hash rate and watch it change ... often up to 20% ... all over the place ... it's not very accurate.

The problem on top of all this is that is if you include the (rare) non-share-chain blocks in your calculation - but don't include the hashes that were used to find those blocks ... so ... your stated luck would be higher than it really is ... hmm that doesn't sound good ... stating it higher than it really is.

jonnybravo0311

legendary

Activity: 1344

Merit: 1024

Mine at Jonny's Pool

Quote from: chalkboard17 on June 07, 2015, 03:39:54 PM

The correct and direct definition of luck (where >100% is good luck and less than 100% is bad luck) is simply DifficultyExpected/DifficultySubmitted

I'm not sure I understand how you would calculate this, wouldn't the submitted diff for a valid block always be greater than or equal to the expected diff ?

We use the average of the stored hashrate since the last block was found by the pool (and we weight and average the difficulty if it changed since last block found) to determine an average expected time to block, then compare that to the actual time for the block in question.

If the the times are equal its 100%

If we found it faster > than 100%

If we found it slower < than 100%

He's referring to the actual number of shares submitted vs the expected shares submitted to find a block. Since p2pool has no real knowledge of any miner's actual hash rate and submitted shares like ckpool does, the best we could do with p2pool is to evaluate how many share-chain shares we'd expect it to take to find a block vs how many share-chain shares were actually submitted to find it.

The problem is the number of expected shares is constantly changing on p2pool because the share difficulty constantly changes, unlike the BTC network where it's static for 2016 blocks. The best you're ever going to get is just an approximation of luck using the expected vs actual figures, so I see no real reason to change the calculations you're currently using, since they're providing an approximation as well.

p3yot33at3r

sr. member

Activity: 266

Merit: 250

Thank you, worked.

Thank kano Wink

It's not persistent - you'll have to do the same after every reboot. Also, change your queue setting to 1 or 0 - whatever works best for you. There's a custom firmware mentioned a few pages back that does all this for you & is persistent - might be better for you.

chalkboard17

sr. member

Activity: 484

Merit: 251

Quote from: p3yot33at3r on June 07, 2015, 08:08:42 AM

Quote from: chalkboard17 on June 07, 2015, 07:38:37 AM

I am using antminer s5 interface and pointing miner to the ip.

Use kano's cgminer replacement - bitmain's cgminer is borked for p2pool:

SSH into your S5 as root then copy/paste:

Code:

cd /tmp
wget http://ck.kolivas.org/apps/cgminer/antminer/s5/4.9.0-150105/cgminer
chmod +x cgminer
mv /usr/bin/cgminer /usr/bin/cgminer.bak
cp cgminer /usr/bin
/etc/init.d/cgminer.sh restart

Then press enter.

Thank you, worked.

windpath

legendary

Activity: 1258

Merit: 1027

Quote from: yslyung on June 07, 2015, 03:15:46 PM

The correct and direct definition of luck (where >100% is good luck and less than 100% is bad luck) is simply DifficultyExpected/DifficultySubmitted

I'm not sure I understand how you would calculate this, wouldn't the submitted diff for a valid block always be greater than or equal to the expected diff ?

We use the average of the stored hashrate since the last block was found by the pool (and we weight and average the difficulty if it changed since last block found) to determine an average expected time to block, then compare that to the actual time for the block in question.

If the the times are equal its 100%

If we found it faster > than 100%

If we found it slower < than 100%

math & coding is hard ...

but afaik with my poor math & coding skills ... p2pool luck is better than kano.is ?

Sometimes it is, sometimes it is not, the nature of luck Wink

yslyung

legendary

Activity: 1500

Merit: 1002

Mine Mine Mine

The correct and direct definition of luck (where >100% is good luck and less than 100% is bad luck) is simply DifficultyExpected/DifficultySubmitted

I'm not sure I understand how you would calculate this, wouldn't the submitted diff for a valid block always be greater than or equal to the expected diff ?

We use the average of the stored hashrate since the last block was found by the pool (and we weight and average the difficulty if it changed since last block found) to determine an average expected time to block, then compare that to the actual time for the block in question.

If the the times are equal its 100%

If we found it faster > than 100%

If we found it slower < than 100%

math & coding is hard ...

but afaik with my poor math & coding skills ... p2pool luck is better than kano.is ?

windpath

legendary

Activity: 1258

Merit: 1027

Quote from: chalkboard17 on June 07, 2015, 07:38:37 AM

The correct and direct definition of luck (where >100% is good luck and less than 100% is bad luck) is simply DifficultyExpected/DifficultySubmitted

I'm not sure I understand how you would calculate this, wouldn't the submitted diff for a valid block always be greater than or equal to the expected diff ?

We use the average of the stored hashrate since the last block was found by the pool (and we weight and average the difficulty if it changed since last block found) to determine an average expected time to block, then compare that to the actual time for the block in question.

If the the times are equal its 100%

If we found it faster > than 100%

If we found it slower < than 100%

p3yot33at3r

sr. member

Activity: 266

Merit: 250

I am using antminer s5 interface and pointing miner to the ip.

Use kano's cgminer replacement - bitmain's cgminer is borked for p2pool:

SSH into your S5 as root then copy/paste:

Code:

cd /tmp
wget http://ck.kolivas.org/apps/cgminer/antminer/s5/4.9.0-150105/cgminer
chmod +x cgminer
mv /usr/bin/cgminer /usr/bin/cgminer.bak
cp cgminer /usr/bin
/etc/init.d/cgminer.sh restart

Then press enter.

Quote from: chalkboard17 on June 07, 2015, 07:38:37 AM

I cannot use my IP to mine, don't know why. I use its network IP and seems to work fine (at lower hashrate). Is that ok?

You should be able to use your LAN IP - is your node on your network or on your PC?

Quote from: chalkboard17 on June 07, 2015, 07:38:37 AM

Can someone take any fees or possibly steal hashrate from me if I use p2pool?

You can see if a node is charging you a fee by adding "/fee" at the end of the node address. It's impossible for anyone to steal your hash if you use your own node.

Quote from: chalkboard17 on June 07, 2015, 07:38:37 AM

Can I merge mine on all merged mining possible coins? At the same time? On windows?

Yes.

chalkboard17

sr. member

Activity: 484

Merit: 251

I have searched everywhere but haven't found an answer to this. Appreciate if someone could help me.
I have been trying to mine on p2pool, but I get much lower hashrate than usual. I normally get 1380gh/s on eligius and ghash. On p2pool I always get ~1230gh/s.
I already tried mining on my node and other people's nodes and result is still the same.
I am using antminer s5 interface and pointing miner to the ip.

I cannot use my IP to mine, don't know why. I use its network IP and seems to work fine (at lower hashrate). Is that ok?

Can someone take any fees or possibly steal hashrate from me if I use p2pool?

Can I merge mine on all merged mining possible coins? At the same time? On windows?
Thanks

p3yot33at3r

sr. member

Activity: 266

Merit: 250

Quote from: yslyung on June 07, 2015, 06:33:19 AM

qt works but not daemon

Exactly. At least on my distro & local node.

yslyung

legendary

Activity: 1500

Merit: 1002

Mine Mine Mine

Quote from: Meuh6879 on June 07, 2015, 06:25:11 AM

Quote from: yslyung on June 06, 2015, 02:16:22 AM

this is not a p2pool direct network payment.

this screen is a pool (perhaps with a NODE connected to a P2Pool).
this POOL pay regulary.

on REAL P2Pool, you are pay when block is found only ... 1 block find with P2Pool = 1 transaction.
history of BLOCK FOUND By P2Pool is here : http://minefast.coincadence.com/p2pool-stats.php

on 6/6/15 ... only 2 blocks are found (02h17 and 15h07).

what are you trying to say ?

we're talking about merged mining uno with p2pool Huh

lost here...maybe you wanna elaborate ?

qt works but not daemon

Meuh6879

legendary

Activity: 1512

Merit: 1012

Quote from: yslyung on June 06, 2015, 02:16:22 AM

this is not a p2pool direct network payment.

this screen is a pool (perhaps with a NODE connected to a P2Pool).
this POOL pay regulary.

on REAL P2Pool, you are pay when block is found only ... 1 block find with P2Pool = 1 transaction.
history of BLOCK FOUND By P2Pool is here : http://minefast.coincadence.com/p2pool-stats.php

on 6/6/15 ... only 2 blocks are found (02h17 and 15h07).

p3yot33at3r

sr. member

Activity: 266

Merit: 250

Hi all, just a heads up.

I'm using Xubuntu 14.04 64bit & have found that when using the Unobtanium daemon for merge mining I'm not receiving any payments, but if I use the QT wallet - payments are received in the normal way. I've recompiled the daemon a few times with no errors & I get no errors in my p2pool logs either - the payments just don't appear in my wallet, yet as soon as I use the QT wallet, payments resume as normal.

I will report the issue on the Unobtanium thread, but I recommend that anyone using the Unobtanium daemon on NIX to check that they are receiving their merge mined payments & if not, to switch to the QT wallet instead. Unfortunately it seems that previous lost payments are just that - lost.

I'm not sure if this issue is the same for other OS's, but I'd check anyway, just to be sure.

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: windpath on June 06, 2015, 11:22:39 PM

Quote from: kano on June 06, 2015, 07:30:36 PM

Quote from: kano on June 06, 2015, 07:30:36 PM

...
Table pool_stats stores the bitcoin difficulty from bitcoind and pool hashrate from p2pool every minute, this is how luck is calculated - and why I could not calculate luck for historical blocks when I built it (no one had historical pool hashrate data).
...

How do you calculate luck?

Basically after a lot of discussion, we ended up with pretty close to what is described here:

https://bitcointalksearch.org/topic/m.7373650

I dug around to find it, the discussion started when p2pool.info went offline almost a year ago (The post is from June 18, 2014).

Edit: I know our stats look crazy high right now, in fact just found another block at 222.82%, but we are on a nice streak.... Take a look at the times between the last 10 blocks we have found, all except 1 much better then expected. We have paid our dues with the bad times recently, looks like it's turned around Wink

Well, those calculations are based on other calculations that have their own accuracy issues.

The correct and direct definition of luck (where >100% is good luck and less than 100% is bad luck) is simply DifficultyExpected/DifficultySubmitted

Those are two number that you should have - the other numbers you use are calculated from them.
The pool hash rate (as you may well have seen) is, like any pool, only an estimate, and not very accurate either.

My real question, though, is do you count blocks that are not part of the share chain?
If you do, then you must also include the hashes used to find those blocks.
Adding a block into your luck figure without including the hashes expended to find that block is, obviously, incorrect.

yslyung

legendary

Activity: 1500

Merit: 1002

Mine Mine Mine

Quote from: kano on June 06, 2015, 07:30:36 PM

...
Table pool_stats stores the bitcoin difficulty from bitcoind and pool hashrate from p2pool every minute, this is how luck is calculated - and why I could not calculate luck for historical blocks when I built it (no one had historical pool hashrate data).
...

How do you calculate luck?

thats wut i wanna add to my node .... & been trying to figure that out.

math looks right to me windpath ....

now a how to for a noob .. thx Wink

windpath

legendary

Activity: 1258

Merit: 1027

...
Table pool_stats stores the bitcoin difficulty from bitcoind and pool hashrate from p2pool every minute, this is how luck is calculated - and why I could not calculate luck for historical blocks when I built it (no one had historical pool hashrate data).
...

How do you calculate luck?

Basically after a lot of discussion, we ended up with pretty close to what is described here:

https://bitcointalksearch.org/topic/m.7373650

I dug around to find it, the discussion started when p2pool.info went offline almost a year ago (The post is from June 18, 2014).

Edit: I know our stats look crazy high right now, in fact just found another block at 222.82%, but we are on a nice streak.... Take a look at the times between the last 10 blocks we have found, all except 1 much better then expected. We have paid our dues with the bad times recently, looks like it's turned around Wink

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4