NastyPoP vs Standard P2Pool

[jonnybravo0311]

Quick update... I noticed the S3 I had pointed at my own p2pool node has gone down.  Unfortunately, I'm away from home this week traveling for work and I do not have remote access to my miners.  I really should set that up .

Anyway, I will not be including numbers for that miner in this upcoming Friday's results.  I will have only 2 on the test: the miner on NastyPoP (which, I switched over to the new protocol on Sunday) and the miner on the standard p2pool payout.

Speaking of the new protocol (ckpool on port 3334 using p2pool as a backend), I've noticed very inconsistent hash rate, with a number of times connectivity has been lost altogether.  I'm guessing it's growing pains as nonnakip just brought this online recently.  Hopefully things settle down shortly.  We'll see what impact, if any, this has come Friday.

Here is a screenshot of the hash rate graphs from nastyfans.org showing my two miners:



Here's another miner using the NastyPoP method:



As you can see, the miners using NastyPoP show some pretty erratic hash rates and loss of connectivity, whereas my miner on the standard p2pool payout is straight across the board.

[1715604871]

1715604871

[1715604871]

1715604871

[1715604871]

1715604871

[OgNasty]

As you can see there were some issues with the ckpool frontend.  nonnakip has been slapping bandages on it while the issues get worked out and ckolivas is aware and actively addressing the issue with the ckpool software, but it is probably a good idea for miners to have the regular p2pool port set as a failover in the meantime.  I guess it's important to remember that NastyPool is still in beta with many features still being actively developed.

[jonnybravo0311]

Not a problem.  I figured it was some growing pains putting Con's pool on a p2pool backbone.  I have faith they'll sort it out.  I just wanted to mention and display the connection issues when I saw them as they may have an effect on this week's test results... Not to mention bring it to your attention

[jonnybravo0311]

As you can see, I have not provided results for the week 1/16 - 1/23.  There were some pretty significant connection issues with Nonnakip's new implementation of ckpool on top of the p2pool framework.  Unfortunately, those issues are still persisting as you can see from this screenshot:



Combine this with the fact that no payouts were received for last week and I am unable to provide any kind of meaningful test results.  Please note, you can see that a payout was attempted by looking here: https://www.blocktrail.com/BTC/tx/c46bd16596240f6b41a10ceb968389c3921214cbff27d6cbe6d987f51bab9c99

Unfortunately, with the changeover to the new NastyPoP system, payouts seem to have gotten confused.  Looking at the payout distribution charts at https://nastyfans.org/nastypool/nastypop_ticker I can see my miner's address listed twice.  The attempted payout matches one of those values (0.02006569 BTC) but there is no mention of the other value.  If we go solely on the attempted value, we'll find that it is significantly lower than what I made on the standard nasty p2pool payout (0.03989456BTC).  The expected payouts for this past week were 0.0352BTC.  P2Pool itself was pretty lucky during these 7 days, so I'm shocked to see such a huge disparity (nearly twice as much) between what I made on the standard payout vs what is reported for the NastyPoP method.

It's quite apparent that something went pretty wrong last week, both with the conversion to the new front end and with the payouts themselves.  The issues still persist today.  I hope Nonnakip is able to get this sorted.

[OgNasty]

It's quite apparent that something went pretty wrong last week, both with the conversion to the new front end and with the payouts themselves.  The issues still persist today.  I hope Nonnakip is able to get this sorted.

The payouts went out, but aren't being confirmed by the network for some reason.  This isn't related to the frontend, but some other mystery.  Here's the transaction that is waiting to confirm: https://www.blocktrail.com/BTC/tx/c46bd16596240f6b41a10ceb968389c3921214cbff27d6cbe6d987f51bab9c99

The conversion to the new frontend went fine as well.  The issue is that ckpool is currently extremely buggy.  I'm beginning to question if ckpool is ready for primetime yet though.  Using the 9332 port will eliminate any issues relating to ckpool until a stable version can be released (even port 3334 is now standard p2pool until ckpool can stabilize), and if last week's distribution isn't confirmed by this week, the coins will be double spent to ensure they are added to this week's distribution.

[jonnybravo0311]

It's quite apparent that something went pretty wrong last week, both with the conversion to the new front end and with the payouts themselves.  The issues still persist today.  I hope Nonnakip is able to get this sorted.

The payouts went out, but aren't being confirmed by the network for some reason.  This isn't related to the frontend, but some other mystery.  Here's the transaction that is waiting to confirm: https://www.blocktrail.com/BTC/tx/c46bd16596240f6b41a10ceb968389c3921214cbff27d6cbe6d987f51bab9c99

The conversion to the new frontend went fine as well.  The issue is that ckpool is currently extremely buggy.  NastyPool is now using an older version of ckpool that seems a little more stable, as well as restarting when an issue is detected.  I'm beginning to question if ckpool is ready for primetime yet though.  Using the 9332 port will eliminate any issues relating to ckpool until a stable version can be released, and if last week's distribution isn't confirmed by this week, the coins will be double spent to ensure they are added to this week's distribution.

I linked the payout transaction in my post.  You're absolutely right that it's a mystery.  I also read your post in the pool thread stating that Nonnakip would be sending out the payments again this coming Friday if they hadn't confirmed by then, so no worries about that.

My primary concern is the discrepancy between what the charts on the site state vs what the payout transaction has.  The charts show miner addresses more than once, each with a value of expected BTC payout.  The payout transaction, however, only has one of those values.  Could you explain that, please?  The reason I'm asking is that during the past week p2pool was over 100% luck, finding more blocks that it should have.  My standard p2pool payouts reflect that; however, my payments in the NastyPoP payout transaction are far below expectations.  As I mentioned, I made nearly double with standard p2pool payouts as I did with NastyPoP.

When you wrote, "using the 9332 port will eliminate..." are you suggesting that people should go back to using stratum+tcp://nastyfans.org:9332 -u WALLETADDRESS-PoP -p x for the NastyPoP payouts?

Thanks for any clarifications.

[-ck]

The payouts went out, but aren't being confirmed by the network for some reason.  This isn't related to the frontend, but some other mystery.  Here's the transaction that is waiting to confirm: https://www.blocktrail.com/BTC/tx/c46bd16596240f6b41a10ceb968389c3921214cbff27d6cbe6d987f51bab9c99

Probably because you're trying to pay dust payments as well.

[OgNasty]

My primary concern is the discrepancy between what the charts on the site state vs what the payout transaction has.  The charts show miner addresses more than once, each with a value of expected BTC payout.  The payout transaction, however, only has one of those values.  Could you explain that, please?  The reason I'm asking is that during the past week p2pool was over 100% luck, finding more blocks that it should have.  My standard p2pool payouts reflect that; however, my payments in the NastyPoP payout transaction are far below expectations.  As I mentioned, I made nearly double with standard p2pool payouts as I did with NastyPoP.

When you wrote, "using the 9332 port will eliminate..." are you suggesting that people should go back to using stratum+tcp://nastyfans.org:9332 -u WALLETADDRESS-PoP -p x for the NastyPoP payouts?

Port 3334 was switched to default p2pool so there is no need to do anything now, but you should probably use port 9332 as a failover just as a good mining practice.

The charts show addresses more than once because the ckpool and p2pool hashes are counted separately.  That means as miners switched ports, their username would then be duplicated.  If you checked while it was happening, you could see that one of the usernames had a "ckp" in front of it, showing that it was mining on the ckpool frontend.  I suspect the reason for your shortpay, without being able to look at the logs (nonnakip would have to help with that) is that ckpool was crashing frequently.  A lot of the miners that were on port 3334 without setting a failover of port 9332 were negatively effected by that.  As I said, I don't have access to see exactly how much downtime you saw as a result of the instability, but it was a major factor last week.  I would definitely recommend that a failover pool always be set for any miner, but it is especially important now while NastyPool works to overcome scalability and stabilization issues.  

I'm not trying to say bad things about ckpool either.  I think it works as a great frontend and am really happy with it while it's operating.

The payouts went out, but aren't being confirmed by the network for some reason.  This isn't related to the frontend, but some other mystery.  Here's the transaction that is waiting to confirm: https://www.blocktrail.com/BTC/tx/c46bd16596240f6b41a10ceb968389c3921214cbff27d6cbe6d987f51bab9c99

Probably because you're trying to pay dust payments as well.

Maybe.  We're part of a crazy bunch that think people should be able to spend dust, or else it shouldn't exist.  I think the core developers haven't paid enough attention to that issue yet.  In any event, it will get resolved.  I just wanted people to know there is no loss and nothing went wrong with the sending of the payment.

[-ck]

Probably because you're trying to pay dust payments as well.

Maybe.  We're part of a crazy bunch that think people should be able to spend dust, or else it shouldn't exist.  I think the core developers haven't paid enough attention to that issue yet.  In any event, it will get resolved.  I just wanted people to know there is no loss and nothing went wrong with the sending of the payment.

That may be, but with the default bitcoind rules that transaction will probably not go through any pool unless you push it to a service that accepts non-standard transactions.

[OgNasty]

Probably because you're trying to pay dust payments as well.

Maybe.  We're part of a crazy bunch that think people should be able to spend dust, or else it shouldn't exist.  I think the core developers haven't paid enough attention to that issue yet.  In any event, it will get resolved.  I just wanted people to know there is no loss and nothing went wrong with the sending of the payment.

That may be, but with the default bitcoind rules that transaction will probably not go through any pool unless you push it to a service that accepts non-standard transactions.

Unless I'm mistaken, it is an 8kb transaction with a 0.0008 BTC transaction fee.  That is the recommended fee, right?  It does appear to me that a combination of young inputs and small outputs are causing the delay.  It will be interesting to see if it gets processed before having to be double spent on Friday.

[nonnakip]

I begin with many thanks to jonnybravo0311. Your work here is excellent. The transparency of the fanclub and pool allows people to have a critical eye. This is to our benefit. Because we are human and we make mistakes.

It's quite apparent that something went pretty wrong last week, both with the conversion to the new front end and with the payouts themselves.  The issues still persist today.

The issues do not exist now because I go back to direct P2Pool. But you are very correct that the past days were very wrong.

• the new CKPool frontend introduced unexpected performance issues (despite very successful testing)
• the payout distribution software mistakingly counted all CKPool-based mining as nastyfans donations
• the distribution transaction was classified low priority and may never be processed

I think the failed transaction processing is a blessing because the transaction contents are wrong. So instead of me adjusting the next payouts and documenting all this errors to compensate for this mishap I will double-spend the correct amounts.

The issue is that ckpool is currently extremely buggy.

You need to be aware that we try running CKPool in a mode (proxy mode) that is not used by other great CKPool-based pools. I do not know if any other pools use this mode. And particularly as a P2Pool frontend. This means NastyPool may trigger problems that exist only for us.

I am grateful to ckolivas for his support during our (unfotunately unsuccessful) integration. I am convinced that CKPool is the correct choice as a pool frontend for NastyPool.

My primary concern is the discrepancy between what the charts on the site state vs what the payout transaction has.  The charts show miner addresses more than once, each with a value of expected BTC payout.  The payout transaction, however, only has one of those values.  Could you explain that, please?

Your concern is legitimate. And it is obvious I must improve how data is displayed. As OgNasty already mention the P2Pool-based and CKPool-based mining is shown separate. This was not technically mandatory. But I wanted this so everyone could keep eyes on statistics. The payout transaction did not include your CKPool-based hashes. This was a error.

I now fixed the distribution payout software and re-run for last distribution. For last mining window 1CVFuGmhMfQJ5hTyYe8fWtKPKNWVpNe8dE will receive 0.02833329 BTC. I plan to double-spend the Bitcoin soon.

I hope Nonnakip is able to get this sorted.

I will.

[jonnybravo0311]

Just a quick update... it looks like Nonnakip double-spent the coins and as a result I received the payout from last week's mining on NastyPoP.  Thanks!  I wasn't expecting the payout until tomorrow, so it was a nice surprise .

Anyway, now that the payout has been received, here are the results for the week of 1/16 - 1/23:

NastyPoP - 0.02833329BTC
NastyP2P - 0.03989456BTC
Expected - 0.0352BTC

I didn't capture the 7 day luck last Friday, so I don't have it to report unfortunately.  There have definitely been some growing pains with the adoption of ckpool as the front end for NastyPoP, and the payout reflects it.  Downtime, restarts, etc contributed, and the lower payout is the result.  Things have gotten a tad more stable this week, so we'll see how it stacks up tomorrow.

OP updated with the results.

Edit: you'll notice that I am not including numbers for a miner on my own node any longer.  Last week when I was traveling for work I noticed that the miner had gone down.  When I returned home, I found the miner had hashed its last hash.  Oh well... it was an early batch S3 that's long since paid for itself.  Moving forward, I'll be running the test only showing the results of standard p2pool payouts vs NastyPoP with both S3s pointing to nastyfans.org.

[OgNasty]

Some info that potentially effects this test:

I found another problem in the nastyfans framework that was introduced with the changes last week. This does not affect nastyfans members. It does affect NastyPoP miners on port 3334. For the last 2 distributions the total hashes of the NastyPoP miners on port 3334 was counted incorrectly. This caused too few BTC to be paid out to these miners. The total magnitude of error look like around 0.4 BTC.

The software is fixed now. I do not have time now to execute the past 2 window hashrate calculations and payouts. I do that soon and post detailed results here. I also post a updated overview of last 4 weeks NastyPoP payouts. Those miners will receive their missed BTC as part of the next distribution

EDIT:

Here is a table showing additional payouts that affected NastyPoP miners will receive for windows 9 and 10. These payouts will be included in the next distribution (window 11).

window 9 = 2015-01-16 - 2015-01-23
window 10 = 2015-01-23 - 2015-01-30

payout address	win9	win10	total
12LnGdSP53vJFRdE9gYp3PHYRG11CKrLmh	0.00098118		0.00098118
14g6E35Ft4msn7JFqV9vCGzegGgVLfFAt1	0.00012296		0.00012296
15SmTha1e1HqjUVAX4kS41UpSvDAc5o1N5		0.00483918	0.00483918
168WXhArv7Fasqvi2xm5MQMfLhG18jifMe	0.04114855	0.01718468	0.05833323
17BfhhsoNSaouxPknAFAYSsKdZ3fVNaCZV		0.00522540	0.00522540
1A3vU4r4typS1jNFfaJjvm77ZHMtqEvB4F	0.00000030	0.00005011	0.00005041
1BUx1eJG7gLwmqP93UTveJzzZngPoL74Cs	0.00002950	0.00001162	0.00004112
1CVFuGmhMfQJ5hTyYe8fWtKPKNWVpNe8dE	0.00406540	0.00228009	0.00634549
1CZYg2kWbbMAqMv7j2aqQ55pZMbGJNSJ2Y		0.00000320	0.00000320
1KoW4kZsvhk2f4eMuuEk1N2MhPre5Nt1My	0.00307181		0.00307181
1L9sTo7SCasupoZDijZ99QscN2sLbukEkP	0.00219292	0.00133443	0.00352735
1MD6Kei3SrgJLpFt4GJtg87VwbfNBXGV1s	0	0.00000015	0.00000015
1MksuCoWpM3oAPxEeswtjB6LCqzfMV6wAa	0	0.01682593	0.01682593
1Nasty12gDYRpo6wvfnCMoMFbHpRSCM6xp	0	0.00005051	0.00005051
1NY4Tdp5bbziY6kGaVeyF6igzogwRioLYj	0.03003851	0.01686257	0.04690108
1PuDcV61BJdnG9nL7Q53Mj51p8wB9K6xsx	0	0.00266828	0.00266828

[jonnybravo0311]

Some info that potentially effects this test:

I found another problem in the nastyfans framework that was introduced with the changes last week. This does not affect nastyfans members. It does affect NastyPoP miners on port 3334. For the last 2 distributions the total hashes of the NastyPoP miners on port 3334 was counted incorrectly. This caused too few BTC to be paid out to these miners. The total magnitude of error look like around 0.4 BTC.

The software is fixed now. I do not have time now to execute the past 2 window hashrate calculations and payouts. I do that soon and post detailed results here. I also post a updated overview of last 4 weeks NastyPoP payouts. Those miners will receive their missed BTC as part of the next distribution

Thanks for the update.  I'll adjust the test numbers when the corrections are sent.

[aurel57]

Just a quick update... it looks like Nonnakip double-spent the coins and as a result I received the payout from last week's mining on NastyPoP.  Thanks!  I wasn't expecting the payout until tomorrow, so it was a nice surprise .

Anyway, now that the payout has been received, here are the results for the week of 1/16 - 1/23:

NastyPoP - 0.02833329BTC
NastyP2P - 0.03989456BTC
Expected - 0.0352BTC

I didn't capture the 7 day luck last Friday, so I don't have it to report unfortunately.  There have definitely been some growing pains with the adoption of ckpool as the front end for NastyPoP, and the payout reflects it.  Downtime, restarts, etc contributed, and the lower payout is the result.  Things have gotten a tad more stable this week, so we'll see how it stacks up tomorrow.

OP updated with the results.

Edit: you'll notice that I am not including numbers for a miner on my own node any longer.  Last week when I was traveling for work I noticed that the miner had gone down.  When I returned home, I found the miner had hashed its last hash. Oh well... it was an early batch S3 that's long since paid for itself.  Moving forward, I'll be running the test only showing the results of standard p2pool payouts vs NastyPoP with both S3s pointing to nastyfans.org.

R.I.P. 

[jonnybravo0311]

Week of 1/23 - 1/30 was very close between standard p2pool payouts and NastyPoP for my S3s.  P2Pool itself was down on luck for the week, so neither standard p2pool nor NastyPoP hit expected earnings.  Numbers:

NastyPoP - 0.01963295BTC
NastyP2P - 0.02061486BTC
Expected - 0.0361BTC
Luck - 81.85%

OP updated with the week's numbers.

[jonnybravo0311]

Week of 1/30 to 2/6 saw my S3 on the standard p2pool suffer.  It hadn't found a share for nearly 5 days, which caused it to miss quite a few block payouts.  Also, as promised, nonnakip compensated for the mistake in share counting from the previous 2 weeks.  As a result, NastyPoP payouts crushed standard p2pool payouts for my miners this week.  Here are the numbers:

NastyPoP - 0.05905592BTC
NastyP2P - 0.02003162BTC
Expected - 0.0375BTC
Luck - 93.32%

As usual, OP updated with this week's numbers.

[jonnybravo0311]

I almost don't even want to bother posting results this week since p2pool found exactly 1 block.  7 days.  1 block.  Ouch, this past week has been some absolutely horrific luck, and of course this past week was the week I thought I'd rent out some significant hashing power.  Yeah, I gambled and lost... and lost big.  If you had asked me last week at this time if I thought p2pool would only find a single block all week I would have said not likely at all.  But here we are, and it did indeed happen.  Am I disgruntled?  A bit .

NastyPoP - 0.00435959BTC
NastyP2P - 0.00938869BTC
Expected - 0.0361BTC
Luck - 14.3%

OP updated as well.

[jonnybravo0311]

And..... another week gone by with p2pool only finding a single block.  Ouch!  My S3 on the standard p2pool payout was a bit lucky and found more shares than it should have, so at least there was a small bit of consolation.

2/13 - 2/20
NastyPoP - 0.00698833BTC
NastyP2P - 0.01822003BTC
Expected - 0.0348BTC

[zvs]

Let's take a look at the ping times from my miner to the pool:

--- nastyfans.org ping statistics ---
57 packets transmitted, 57 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 115.153/144.510/277.534/45.255 ms

An average of 144.51 would stop me from pointing a miner there if it were a standard p2pool node.  Let's see where the server is.  Running a traceroute shows the last hop in Germany.  Well, that explains the ping time - I had to go to Europe .  Our friends on that side of the pond would probably be better served.

I used a p2pool with 200ms latency for at least half a year.  

Bitcoin should have less interrupts than DOGE, but since DOGE is the one I remember.... DOGE had one minute block time avg.  I don't remember for sure, but I think it also had 15s share time in p2pool.  So on average, you'd get 5 interrupts a minute.  At 200ms latency, that means at worst you'd be sent some new work, 0.00001ms later there would be a new share/block, requiring the server to send you some new work.  So then you have the 200ms to receive the work, then 200 + a few more ms before you start sending this work back, just call it 400ms.  Five interrupts a minute = 2000ms = 2 out of 60 seconds = 3.33% DOA.  Bitcoin has less interrupts.  Two shares per minute, right?  Then the block that's supposed to be every 15m but on increasing difficulty is a bit faster.   So you're talking less than 1.5% DOA there.

anyway, lower orphan rate of having the pool in Europe more than made up for that for me....  though if I was in Europe, I probably wouldn't be too keen on using a p2pool in the US or Asia, since most the (good) p2pools are hosted in datacenters in germany, france, or the netherlands.