[1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool

[IYFTech]

2 petahash/second (and rising), 110% 90 day luck, 12 hour blocks (and dropping). It's very positive to be on p2pool right now

Pretty damn good for a supposedly "flawed" payout system eh?    (without quoting  )

[ceslick]

Lol!!!

Just need more shares!!! Blocks are happening a lot more regularly now

[KyrosKrane]

My UI reports that I currently have 77 shares, and it's been in the 60-80 range pretty consistently for the last several days. I got regular payouts for all the blocks found yesterday (and, in fact, for the last few weeks).  However, I didn't get paid for today's two blocks. Why would that be?

OK, this is bad.  I haven't gotten anything from any of the blocks in the last 24+ hours. And I have no clue why not.

Edit: P2pool reports:

P2Pool: 17384 shares in chain (17388 verified/17388 total) Peers: 7 (1 incoming)
Local: 218GH/s in last 10.0 minutes Local dead on arrival: ~11.6% (7-18%) Expected time to share: 1.3 days
Shares: 77 (6 orphan, 6 dead) Stale rate: ~15.6% (9-26%) Efficiency: ~97.8% (86-106%) Current payout: 0.0000 BTC
Pool: 1900TH/s Stale rate: 13.7% Expected time to block: 12.4 hours

[contactlight]

My UI reports that I currently have 77 shares, and it's been in the 60-80 range pretty consistently for the last several days. I got regular payouts for all the blocks found yesterday (and, in fact, for the last few weeks).  However, I didn't get paid for today's two blocks. Why would that be?

OK, this is bad.  I haven't gotten anything from any of the blocks in the last 24+ hours. And I have no clue why not.

Edit: P2pool reports:

P2Pool: 17384 shares in chain (17388 verified/17388 total) Peers: 7 (1 incoming)
Local: 218GH/s in last 10.0 minutes Local dead on arrival: ~11.6% (7-18%) Expected time to share: 1.3 days
Shares: 77 (6 orphan, 6 dead) Stale rate: ~15.6% (9-26%) Efficiency: ~97.8% (86-106%) Current payout: 0.0000 BTC
Pool: 1900TH/s Stale rate: 13.7% Expected time to block: 12.4 hours

I am not having any problems. I got paid for each and every block in the last 24 hours.

[rav3n_pl]

My UI reports that I currently have 77 shares, and it's been in the 60-80 range pretty consistently for the last several days. I got regular payouts for all the blocks found yesterday (and, in fact, for the last few weeks).  However, I didn't get paid for today's two blocks. Why would that be?

OK, this is bad.  I haven't gotten anything from any of the blocks in the last 24+ hours. And I have no clue why not.

Edit: P2pool reports:

P2Pool: 17384 shares in chain (17388 verified/17388 total) Peers: 7 (1 incoming)
Local: 218GH/s in last 10.0 minutes Local dead on arrival: ~11.6% (7-18%) Expected time to share: 1.3 days
Shares: 77 (6 orphan, 6 dead) Stale rate: ~15.6% (9-26%) Efficiency: ~97.8% (86-106%) Current payout: 0.0000 BTC
Pool: 1900TH/s Stale rate: 13.7% Expected time to block: 12.4 hours

Expected time to share: 1.3 days
Expected time to block: 12.4 hours
Your shares are paid and you not have new one.

[CartmanSPC]

as stated there a flaw in the p2 system if i can do that by just turn the manual diff up as this test is proving quite well  

Sorry to quote but wanted to point out the p2pool will only allow you to increase your share diff up to 30 times the minimum no matter what you set.

[bitcoinbearhk]

Hi the P2Pool Brotherhood,

I am a pre-CEX.io miner, now looking to switch pool.  CEX crap.

Really want to join this P2Pool order.  Want to learn more without going through 500 pages of forum ......

May I kindly ask:

1) Do I need to setup my own node, with a designated computer + fixed IP address, to mine with my miners pointing their "pool" to the node IP?

2) Are there any public node to connect to like the p2pool.org They are great even with 2% fee, but I only see a very small countable numbers of miners with them... I suppose all of you out there have some more smart way to do this ...

3) I tried to build my own node, and of course 1st of all download the "bitcoin core" for the fresh computer ... it is downloading the block slow like shit ... already downloading for 1 whole day now, and I don't see it can complete it in without spending over 1 week to do so ... this doesn't look right ... any quick way so that I can start joining the p2pool brotherhood any sooner?

[Hunterbunter]

Hi the P2Pool Brotherhood,

I am a pre-CEX.io miner, now looking to switch pool.  CEX crap.

Really want to join this P2Pool order.  Want to learn more without going through 500 pages of forum ......

May I kindly ask:

1) Do I need to setup my own node, with a designated computer + fixed IP address, to mine with my miners pointing their "pool" to the node IP?

2) Are there any public node to connect to like the p2pool.org They are great even with 2% fee, but I only see a very small countable numbers of miners with them... I suppose all of you out there have some more smart way to do this ...

3) I tried to build my own node, and of course 1st of all download the "bitcoin core" for the fresh computer ... it is downloading the block slow like shit ... already downloading for 1 whole day now, and I don't see it can complete it in without spending over 1 week to do so ... this doesn't look right ... any quick way so that I can start joining the p2pool brotherhood any sooner?

Best is to build your own node.

In the mean time, you can connect to any of the public p2pool nodes while you set  yours up:

http://p2pool-nodes.info/
http://p2pool.jir.dk/bitcoin/

I also have a node which pays out a bonus in devcoins (20% of whatever p2pool pays you), while I'm testing out an unofficial devcoin client: http://blisterpool.com

My UI reports that I currently have 77 shares, and it's been in the 60-80 range pretty consistently for the last several days. I got regular payouts for all the blocks found yesterday (and, in fact, for the last few weeks).  However, I didn't get paid for today's two blocks. Why would that be?

OK, this is bad.  I haven't gotten anything from any of the blocks in the last 24+ hours. And I have no clue why not.

Edit: P2pool reports:

P2Pool: 17384 shares in chain (17388 verified/17388 total) Peers: 7 (1 incoming)
Local: 218GH/s in last 10.0 minutes Local dead on arrival: ~11.6% (7-18%) Expected time to share: 1.3 days
Shares: 77 (6 orphan, 6 dead) Stale rate: ~15.6% (9-26%) Efficiency: ~97.8% (86-106%) Current payout: 0.0000 BTC
Pool: 1900TH/s Stale rate: 13.7% Expected time to block: 12.4 hours

Highlighted the important bit - you don't have any paying shares. The 77 shares you have wouldn't be part of the PPLNS conveyor any more.

[Hunterbunter]

If I have 2 miners, and put one on one node, and the second on a separate one, both with the same bitcoin address, does anything weird happen?

Each node should report the proper hashrate of that particular miner, but the shares shown should be higher than expected, right?

ie miner 1 gets a share an hour, miner 2 gets a share an hour, each node show that the address is earning 2 shares an hour?

[fire000]

as stated there a flaw in the p2 system if i can do that by just turn the manual diff up as this test is proving quite well  

Sorry to quote but wanted to point out the p2pool will only allow you to increase your share diff up to 30 times the minimum no matter what you set.

That an incorrect statement there sorry a simple 10 min test on any p2 alt coin will highlight this ....   And lifting the min diff above that 30 x this can be highlight well on the node I was using for the test it had a share diff off 1000 the setting I was using was 40000 and it was accpecting them shares at the 40000 value so they were set at x 40 the diff and they were the only shares being put into the node...   any thing under that value are not appected  A very quick test can disprove your above statement that you can carry out...And watching ya cgminer interface and the shares going into the node as credited shares or even the block chain it self as

And no matter what the coin if BTC of xjo tek trc etc the p2 network is the same from coin to coin in it set up as it all uses the same software to set the nodes up....

[cathoderay]

                                                             TROLL ALERT!!!

[fire000]

                                                            TROLL ALERT!!!

Lmao I looking froward to shooting ya down in 7 days as is starting work on the p2 node payout flaw with 2 different miners <<<<<    on 2 different address on 2 diff diff settings looks forward to this got to say atm miner one (the one with the manual diff set) is killing miner 2 (on the base share rate) by 75 percent earning wise...    I will drop the payout address and the node these miners are on at the end of day 1 and will dump the numbers for the next 7 days.....    As well as the direct link to the blockchain that show the balance to both address and the transactions of them address got nothing to hide here as the test is showing well at this stage the flaw in the p2 payout system.

Ps if the early results are any thing to go by 7 days x 75 percent that is a massive 525 percent diffence in the 2 miners payouts running at the same hash rate over 7 days...    when they should be close to 50/50 split gave or take a couple percent for luck    But not 5 times the diffence in terms of payout if these result keep up as they have been

So keep going hun as I so going to enjoy this when the theory is backed up by cold hard testing.....  Then ya can sit there and try to explain to me and every p2 user why a manual overwrite command can be used to manulpe the payouts on the p2 pool system ?  


Ps cathoderay/PatMan it is easy for one to sit there and go troll troll etc I could call ya a troll etc....   BUT on saying this I am yet to see you disprove THE above with any testing or cold hard proof........

Where on the other hand I have already done 2 short tests one that was 6hrs and the second that was planned to last a few day till the control disappered of a node so had to scrape that test.....  And BOTH of them have already shown there is an issue there and others have seen it 1st hand.....      Now is in the next phase of testing and that is one a longer time test to kill of the theory of it been a luck issue etc....    

Maybe step up and disapprove the above before shooting off there hun as I have and am still doing tests to back these claims up....  DON"T see you doing any of the above to disprove it so before shooting off behind ya keyboard labelling someone as a troll maybe put ya rigs to work trying to disprove the above then come out with that statement with cold facts that there is not an issue there....    <<<< but at this point of time it not looking good from them 2 past tests and the current testing I am doing ....



Also to the luck issue a few brought up I have been thinking about this one a bit on the 1st test which done on a XJO node that coin has the following specs

Hashing algo: SHA-256
Block time: 45 seconds
Block reward: 16 XJO

Now off the specs in that 6 hour test there would of been roughly 460-500 blocks hit on the chain (not a small sample of block by any means)  vs   the btc at 36 -42 blocks if it ran to specs....    So in theory in that 6hrs of testing there was 11-14 times the blocks hits compare to the btc  gave or take a couple blocks.....    

Now on xjo to mirror the btc chain of 2016 to each diff rise of 10-12 days.....     if one was mining on XJO it would be just over a day of mining on that coin to chew through a 10-12 days worth of BTC mining.....     Just thought I would point that one out for people to think about re the luck thing....     So with the new test I will be doing over 7 days there will be around 13,400 blocks hit in them 7 days it coin was on target which is = to 6 diff rises in the BTC or about 10-12 weeks of btc mining

[IYFTech]

So far I'm finding my S3's work best using "--queue 0 --failover-only" in the /etc/init.d/cgminer settings - I'd be interested in hearing what you guys are using as a comparison?

Ta  

Edit: Decided to implement the ignore button for the first time ever - what a difference!! Bye bye troll 

[windpath]

If I have 2 miners, and put one on one node, and the second on a separate one, both with the same bitcoin address, does anything weird happen?

Each node should report the proper hashrate of that particular miner, but the shares shown should be higher than expected, right?

ie miner 1 gets a share an hour, miner 2 gets a share an hour, each node show that the address is earning 2 shares an hour?

The expected payout will be the sum of both miners, however the shares found that are displayed will be unique on each node as each node only displays its own found shares (this is true for all current front ends I am aware of).

[jonnybravo0311]

So far I'm finding my S3's work best using "--queue 0 --failover-only" in the /etc/init.d/cgminer settings - I'd be interested in hearing what you guys are using as a comparison?

Ta  

Edit: Decided to implement the ignore button for the first time ever - what a difference!! Bye bye troll 

ckolivas recommended to use at least queue 1 and not queue 0.  Also, I just use the default failover option (since my backup pools are p2pool nodes, it really doesn't matter on which one I'm mining).

I've tried virtually every incarnation of settings on my S3s: queue, expiry, scan-time, manual share diff, manual pseudo-diff, etc.  I have detected absolutely zero difference in performance.  As I mentioned many pages ago in this thread, the only thing I've ever seen is that the value of "Best Share" is always "0" when I set my miner to use /#+#.

YMMV though.  One thing I have noticed is that the S3 is finicky.  Right when you think it's good to go and stable, something else pops up.  Just because I noticed no difference, somebody else might.

[Duce]

So far I'm finding my S3's work best using "--queue 0 --failover-only" in the /etc/init.d/cgminer settings - I'd be interested in hearing what you guys are using as a comparison?

Ta  

Edit: Decided to implement the ignore button for the first time ever - what a difference!! Bye bye troll  

ckolivas recommended to use at least queue 1 and not queue 0.  Also, I just use the default failover option (since my backup pools are p2pool nodes, it really doesn't matter on which one I'm mining).

I've tried virtually every incarnation of settings on my S3s: queue, expiry, scan-time, manual share diff, manual pseudo-diff, etc.  I have detected absolutely zero difference in performance.  As I mentioned many pages ago in this thread, the only thing I've ever seen is that the value of "Best Share" is always "0" when I set my miner to use /#+#.

YMMV though.  One thing I have noticed is that the S3 is finicky.  Right when you think it's good to go and stable, something else pops up.  Just because I noticed no difference, somebody else might.

I too use a queue of 1 after testing the with stock setting following the CK guidance. https://bitcointalk.org/index.php?topic=18313.msg8036549#msg8036549

[IYFTech]

Yeah, I read that advice from ck, and noticed a few others were using --queue 1 as well. I noticed that my HW errors were slightly lower using that setting - but my reject/stale rate was slightly higher, whereas using --queue 0 resulted in the opposite - slightly higher HW errors but slightly lower reject/stale rate, so decided to go for --queue 0 & the lower stale/reject rate......still not sure though TBH.......

And yes, finicky is a good description. Now & then I get the odd "x" pop up & Antmonitor doesn't seem to reboot them always, so I have to keep an eye on them myself......

EDIT: I also get around 10Gh/s more with --queue 0. It just seems slightly more stable......

[nicojuritz]

P2pool makes a lot sense, keep up the good work.

[jonnybravo0311]

Yeah, I read that advice from ck, and noticed a few others were using --queue 1 as well. I noticed that my HW errors were slightly lower using that setting - but my reject/stale rate was slightly higher, whereas using --queue 0 resulted in the opposite - slightly higher HW errors but slightly lower reject/stale rate, so decided to go for --queue 0 & the lower stale/reject rate......still not sure though TBH.......

And yes, finicky is a good description. Now & then I get the odd "x" pop up & Antmonitor doesn't seem to reboot them always, so I have to keep an eye on them myself......

Yup, the mysterious "x" that randomly will show up, drop your hash rate by 15GH/s or so and disappears.  Changing miner configuration from the UI, but the mining process never actually starts.  Clocking 1 unit at 218.75, another at 212.5, another at 225, to find the most stable speed.  Some units with unbelievably low HW errors, others with high rates.  Some with high rejects, some with low.

I've ordered from batch 1, batch 4 and batch 5.  Even in batch 5 the issues remain, although I did get "lucky" as one of my batch 5 units actually hashes at 504GH/s stable.

EDIT: I also get around 10Gh/s more with --queue 0

Yet another example of differences in things.  I've never noticed any hash rate difference on my units by setting queue to 0, 1 or stock at 4096.

[IYFTech]

I've ordered from batch 1, batch 4 and batch 5.  Even in batch 5 the issues remain, although I did get "lucky" as one of my batch 5 units actually hashes at 504GH/s stable.

I also have one of those lucky ones at 505Gh/s from B1 - it's the most stable one out the lot!!