Bitcoin Forum
February 21, 2020, 06:48:56 AM *
News: Latest Bitcoin Core release: 0.19.0.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 [636] 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 ... 814 »
  Print  
Author Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool  (Read 2586980 times)
kano
Legendary
*
Offline Offline

Activity: 3066
Merit: 1242


Linux since 1997 RedHat 4


View Profile
June 07, 2015, 12:30:36 AM
 #12701

...
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?

Pool: https://kano.is 0.1 BTC bonus - low fee PPLNS 3 Days Here on Bitcointalk: Forum
Discord support invite at https://kano.is/ Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
1582267736
Hero Member
*
Offline Offline

Posts: 1582267736

View Profile Personal Message (Offline)

Ignore
1582267736
Reply with quote  #2

1582267736
Report to moderator
1582267736
Hero Member
*
Offline Offline

Posts: 1582267736

View Profile Personal Message (Offline)

Ignore
1582267736
Reply with quote  #2

1582267736
Report to moderator
1582267736
Hero Member
*
Offline Offline

Posts: 1582267736

View Profile Personal Message (Offline)

Ignore
1582267736
Reply with quote  #2

1582267736
Report to moderator
Bitcoin Poker 3.0
The Largest Bitcoin Poker Site
Bad Beat Jackpot Available
No Limit Texas Hold'em Cash Games And Tournaments
PLAY NOW
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1582267736
Hero Member
*
Offline Offline

Posts: 1582267736

View Profile Personal Message (Offline)

Ignore
1582267736
Reply with quote  #2

1582267736
Report to moderator
1582267736
Hero Member
*
Offline Offline

Posts: 1582267736

View Profile Personal Message (Offline)

Ignore
1582267736
Reply with quote  #2

1582267736
Report to moderator
1582267736
Hero Member
*
Offline Offline

Posts: 1582267736

View Profile Personal Message (Offline)

Ignore
1582267736
Reply with quote  #2

1582267736
Report to moderator
windpath
Legendary
*
Offline Offline

Activity: 1256
Merit: 1022


View Profile WWW
June 07, 2015, 04:22:39 AM
 #12702

...
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://bitcointalk.org/index.php?topic=18313.msg7373650#msg7373650

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

yslyung
Legendary
*
Offline Offline

Activity: 1500
Merit: 1000


Mine Mine Mine


View Profile
June 07, 2015, 05:31:04 AM
 #12703

...
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
kano
Legendary
*
Offline Offline

Activity: 3066
Merit: 1242


Linux since 1997 RedHat 4


View Profile
June 07, 2015, 08:20:53 AM
 #12704

...
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://bitcointalk.org/index.php?topic=18313.msg7373650#msg7373650

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.

Pool: https://kano.is 0.1 BTC bonus - low fee PPLNS 3 Days Here on Bitcointalk: Forum
Discord support invite at https://kano.is/ Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
p3yot33at3r
Sr. Member
****
Offline Offline

Activity: 266
Merit: 250



View Profile
June 07, 2015, 10:22:48 AM
 #12705

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.
Meuh6879
Legendary
*
Offline Offline

Activity: 1512
Merit: 1009



View Profile
June 07, 2015, 11:25:11 AM
 #12706



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).
yslyung
Legendary
*
Offline Offline

Activity: 1500
Merit: 1000


Mine Mine Mine


View Profile
June 07, 2015, 11:33:19 AM
 #12707



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).

Huh 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
p3yot33at3r
Sr. Member
****
Offline Offline

Activity: 266
Merit: 250



View Profile
June 07, 2015, 11:45:37 AM
 #12708

qt works but not daemon

Exactly. At least on my distro & local node.
chalkboard17
Sr. Member
****
Offline Offline

Activity: 481
Merit: 250



View Profile
June 07, 2015, 12:38:37 PM
 #12709

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

                ▄▄  ▄▄                
            ██  ▀▀  ▀▀   ██           
        ██                   ██
       
                ██  ██  ▄▄            
     ██    ██           ▀▀  ▄▄        
                  ███       ▀▀        
   ██    ██   ███      ███     ██     
                          ███         
  ██   ██   ██    ███ ███    ▄▄   ██  
               ███           ▀▀       
  ██   ██  ███           ███  ██   ██ 
                     ███              
    ▄▄  ██    ███ ███     ▄▄  ██   ██ 
    ▀▀    ▄▄              ▀▀          
      ▄▄  ▀▀          ███    ██   ██  
      ▀▀      ██  ███                 
         ██              ███    ███   
             ██  ██  ███              
       ██                    ██       
           ███  ▄▄▄  ▄▄  ███          
                ▀▀▀  ▀▀               
 
STREAMITY
 

 

  Twitter
Facebook
Instagram
  Telegram
LinkedIn
Medium
p3yot33at3r
Sr. Member
****
Offline Offline

Activity: 266
Merit: 250



View Profile
June 07, 2015, 01:08:42 PM
 #12710

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.

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?

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.

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

Yes.
windpath
Legendary
*
Offline Offline

Activity: 1256
Merit: 1022


View Profile WWW
June 07, 2015, 06:01:00 PM
 #12711


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%
yslyung
Legendary
*
Offline Offline

Activity: 1500
Merit: 1000


Mine Mine Mine


View Profile
June 07, 2015, 08:15:46 PM
 #12712


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
*
Offline Offline

Activity: 1256
Merit: 1022


View Profile WWW
June 07, 2015, 08:27:30 PM
 #12713


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
chalkboard17
Sr. Member
****
Offline Offline

Activity: 481
Merit: 250



View Profile
June 07, 2015, 08:39:54 PM
 #12714

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.

                ▄▄  ▄▄                
            ██  ▀▀  ▀▀   ██           
        ██                   ██
       
                ██  ██  ▄▄            
     ██    ██           ▀▀  ▄▄        
                  ███       ▀▀        
   ██    ██   ███      ███     ██     
                          ███         
  ██   ██   ██    ███ ███    ▄▄   ██  
               ███           ▀▀       
  ██   ██  ███           ███  ██   ██ 
                     ███              
    ▄▄  ██    ███ ███     ▄▄  ██   ██ 
    ▀▀    ▄▄              ▀▀          
      ▄▄  ▀▀          ███    ██   ██  
      ▀▀      ██  ███                 
         ██              ███    ███   
             ██  ██  ███              
       ██                    ██       
           ███  ▄▄▄  ▄▄  ███          
                ▀▀▀  ▀▀               
 
STREAMITY
 

 

  Twitter
Facebook
Instagram
  Telegram
LinkedIn
Medium
p3yot33at3r
Sr. Member
****
Offline Offline

Activity: 266
Merit: 250



View Profile
June 07, 2015, 09:07:59 PM
 #12715

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.
jonnybravo0311
Legendary
*
Offline Offline

Activity: 1344
Merit: 1015


Mine at Jonny's Pool


View Profile WWW
June 08, 2015, 02:54:22 PM
 #12716


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.

Jonny's Pool - Mine with us and help us grow!  Support a pool that supports Bitcoin, not a hardware manufacturer's pockets!  No SPV cheats.  No empty blocks.
kano
Legendary
*
Offline Offline

Activity: 3066
Merit: 1242


Linux since 1997 RedHat 4


View Profile
June 08, 2015, 11:20:40 PM
 #12717


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.

Pool: https://kano.is 0.1 BTC bonus - low fee PPLNS 3 Days Here on Bitcointalk: Forum
Discord support invite at https://kano.is/ Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
jonnybravo0311
Legendary
*
Offline Offline

Activity: 1344
Merit: 1015


Mine at Jonny's Pool


View Profile WWW
June 09, 2015, 12:11:02 AM
 #12718


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.
You can't include the share difficulty of the shares that are orphaned/dead that solve blocks because those shares are never transmitted to the p2pool network.  Furthermore, even standard orphaned/dead shares can't ever be counted for the same reason - they aren't transmitted.  The only thing you've got is what can be gleaned from the share chain itself, which would only ever be accurate if absolutely there were no orphans or dead... which you're pretty much guaranteed to never have happen Smiley.

In effect, any calculation of luck is ALWAYS going to be higher than actuality because of orphaned/dead shares that never make it onto the share chain.

EDIT: I forgot to mention that the share chain doesn't keep record of all shares, so there is also the possibility that some shares drop off the chain between block finds.  So unless you're recording every share that is submitted (which you certainly should be if you're trying to capture luck) your calculations will be off from there as well.

Jonny's Pool - Mine with us and help us grow!  Support a pool that supports Bitcoin, not a hardware manufacturer's pockets!  No SPV cheats.  No empty blocks.
yslyung
Legendary
*
Offline Offline

Activity: 1500
Merit: 1000


Mine Mine Mine


View Profile
June 09, 2015, 12:15:29 AM
 #12719


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.
You can't include the share difficulty of the shares that are orphaned/dead that solve blocks because those shares are never transmitted to the p2pool network.  Furthermore, even standard orphaned/dead shares can't ever be counted for the same reason - they aren't transmitted.  The only thing you've got is what can be gleaned from the share chain itself, which would only ever be accurate if absolutely there were no orphans or dead... which you're pretty much guaranteed to never have happen Smiley.

In effect, any calculation of luck is ALWAYS going to be higher than actuality because of orphaned/dead shares that never make it onto the share chain.

minus the DOA "should" be closer to actual luck ?

well even taking away the 20% is still good luck & i hope it continues.

mine on ! 
kano
Legendary
*
Offline Offline

Activity: 3066
Merit: 1242


Linux since 1997 RedHat 4


View Profile
June 09, 2015, 01:36:40 AM
 #12720


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.
You can't include the share difficulty of the shares that are orphaned/dead that solve blocks because those shares are never transmitted to the p2pool network.  Furthermore, even standard orphaned/dead shares can't ever be counted for the same reason - they aren't transmitted.  The only thing you've got is what can be gleaned from the share chain itself, which would only ever be accurate if absolutely there were no orphans or dead... which you're pretty much guaranteed to never have happen Smiley.

In effect, any calculation of luck is ALWAYS going to be higher than actuality because of orphaned/dead shares that never make it onto the share chain.

minus the DOA "should" be closer to actual luck ?

well even taking away the 20% is still good luck & i hope it continues.

mine on !  
Ignoring the non-share-chain blocks would give you a valid luck value for the share-chain p2pool blocks - using the simple DifficultyExpected/DifficultySubmitted

The only catch of course would be to know if the non-share-chain blocks have roughly the same expected luck as the normal blocks.
i.e. is there some code/network related factor that affects their luck differently to the others?
The assumption would probably be no difference.

A very rough estimate of the non-share-chain blocks work would be 95% of all the pool's stale work - since it is that work (and only that work) that produces those blocks.
"95%" since on average, 19 out of 20 share-chain shares are submitted when there isn't a network block change.
... 30s per share = average 20 share changes per block change (on a 0% diff change), but only one of the 20 is a block change.

Pool: https://kano.is 0.1 BTC bonus - low fee PPLNS 3 Days Here on Bitcointalk: Forum
Discord support invite at https://kano.is/ Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
Pages: « 1 ... 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 [636] 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 ... 814 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!