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

Yeah, posted it in kanos thread by mistake - deleted it as soon as I realized  

Since you asked in both threads... figured I'd reply to you in both .  No, I don't use any monitoring software applications.  You might want to give mdude77 a shout out to see if he's planning to update his app to support the standard APIs (that kano uses with his updated stuff) in addition to the Bitmain ones.  Not sure how much effort it would be on his part, but it's worth asking.  Of course, this is assuming you're using his monitoring app .  If not, check out the threads for those apps and ask the developers.

Hiya JB,

Regarding kanos latest firmware:


....did you manage to get the hash rate stats up on mmonitor/cryptoglance by any chance? If so, what flags are you using?

Thanks.

I upgraded to the latest commit and no longer see the blank spaces.  Forrestv, thanks for the work you've done, both in creating p2pool in the first place and the recent updates to ensure we don't get left behind when BIP66 goes into effect.

I have sent a small donation to the BTC address you have listed in the README.md in the github repo of p2pool.  It isn't much, but it does reflect 1% of the total I've mined on p2pool since I started here early last year.  The TxID is: 237b9a5b1f444274bb8320e1eee04179dd6b4446ddd2e2948002c8b889c3c31d.  I've also added a 1% donation on my node using the --give-author parameter.

Thanks again for your work.

This is great news!

it is 

New work for worker! Difficulty: 500.000000 Share difficulty: 5696067.651468 Total block value: 25.026283 BTC including 62 transactions

for other workers, some show some don't.

Cool. I'm not sure what info was being missed in the blanks (maybe it was merge mining info - can't remember tbh), but is it possible to show what actual coin block was found/submitted instead of the general "merge mined work"? ie NMC, I0C or whatever?

I think the commit I just pushed should remove them.

Also, we're at 94.7% converted (averaged over the last hour)! Looks like someone big upgraded recently.

Are you sure? I still got the blanks too - I think everyone has........

Edit: Oh, hello forrestv - any news on this blank thing? 

No, not yet. You can watch http://bitcoin.sipa.be/ver-2k.png for the red line crossing 2.95 or run:


which will return 950 or higher when BIP66 takes effect.

Has BIP66 taken effect yet?

still got the blanks.
[/quote]

I just upgraded and I don't see any off the blanks you guys are getting.

yeah i see that too

2015-07-03 00:50:49.745000  Pool: 2163TH/s Stale rate: 14.9% Expected time to block: 1.1 days
2015-07-03 00:50:50.927000 Switchover imminent. Upgraded: 67.767% Threshold: 95.000%
2015-07-03 00:50:50.927000
2015-07-03 00:50:50.958000 Switchover imminent. Upgraded: 67.767% Threshold: 95.000%
2015-07-03 00:50:50.958000
2015-07-03 00:50:50.983000 Switchover imminent. Upgraded: 67.767% Threshold: 95.000%
2015-07-03 00:50:50.984000
2015-07-03 00:50:51.018000 Switchover imminent. Upgraded: 67.767% Threshold: 95.000%
2015-07-03 00:50:51.018000
2015-07-03 00:50:51.042000 Switchover imminent. Upgraded: 67.767% Threshold: 95.000%
2015-07-03 00:50:51.042000
2015-07-03 00:50:51.066000 Switchover imminent. Upgraded: 67.767% Threshold: 95.000%
2015-07-03 00:50:51.066000
2015-07-03 00:50:51.096000 Switchover imminent. Upgraded: 67.767% Threshold: 95.000%
2015-07-03 00:50:51.096000
2015-07-03 00:50:52.763000 P2Pool: 17357 shares in chain (17361 verified/17361 total) Peers: 10 (0 incoming)


still got the blanks.

Not high, the indicator on the command box ... 

Yes. This is mostly due to more transactions in mempool, if my understanding is correct. This affects all of us on p2pool. This means that everybody's DOA and stale share rates will go up while the stress test is in progress. As such, your mining efficiency will only change if your GetBlockTemplate latency is affected more (or less) than other p2pool nodes' latencies.

http://statoshi.info/dashboard/db/transactions

Compare the GBT latency graph with the blue line (txInMemoryPool) in the graph below it in this image:

My bitcoind GetBlockTemplate latency is really suffering - I presume it's due to the clown who decided to "stress test" the network with spam? 

Yes, I saw this, but I guess I misunderstood it. When you said "manually trigger it", I didn't understand exactly what you meant. In the absence of details of how that manual trigger would occur, I presumed that it would mean a local configuration change on each p2pool node or a small code change, requiring another update. Do you have a key that allows you to broadcast a message that tells all v14 nodes to switch over to v14 exclusive mode, or something like that?

jtoomim, did you see my last response to you? The situation is dire, but nowhere near as dire as you think. All non-14.0 miners can be separated from once BIP66 takes effect, so people who have upgraded will be at no disadvantage.

We're not going to make it at this rate.

I see 65% are using version 14. Since we have to achieve 95%, it might sound like we're 2/3 of the way there. In reality, it's much worse than that. What we actually have to do is reduce the amount of hashrate still on the old version by a factor of 7. We need to cut the amount of hashrate using the old version in half almost three times to get there.

Each effort we make to publish about the hard fork will convince the easiest people to reach. The ones left behind will be harder. This means that going from 70% to 85% will be harder than going from 0% to 50% was.

Let's assume we only make it to 94%. If we continue to reward people on version 13 even after BIP66 takes effect, then both those on version 13 and 14 will get about 94% of what their work is worth (assuming 80% conversion to 14). Since the ones on 14 are the people who are paying attention, they will quickly notice that they're not getting paid as much as they ought to, and a few will abandon p2pool. This will increase the proportion using 13, which strengthens the incentive for v14 users to leave. The end result is that p2pool is left to a handful of people who aren't paying attention and aren't making any revenue. Basically, p2pool dies, and during its death throes the people who are slow to leave lose out on mining revenue.

On the other hand, if we stop rewarding v13 before BIP66, then a few people who aren't paying attention lose some money. They might notice that their stale share rate increases dramatically, or they might not. People who are on v14 continue to make as much revenue as they deserve, and as soon as a person on v13 notices something is wrong, they either switch to a traditional pool or they upgrade to v14. The end result is that p2pool shrinks at most by whatever percentage is left on v13. A few people will get butthurt. P2pool survives.

I think that the amount of time during which both BIP66 is in effect and which v13 users are rewarded for their efforts should be zero. My preference would be to publish a version of p2pool that excludes v13 from the share chain 12 to 24 hours before BIP66.

Forrestv, if we did this, would we have to hard fork again to v15, and have another consensus detection round to eliminate v13, or is it possible to make existing v14 nodes exclude v13 without another software upgrade?

Would it be better to just initiate a new p2pool share chain with no v13 (or v14) blocks in it, and have it be a parallel system to the existing long p2pool share chain?