It is possible that we left 300TH behind in the last hard fork, but I can't see how that many folks would mine away for that long without noticing, seems crazy to me....
not good. .
Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool - page 96. (Read 2591920 times)
February 26, 2016, 10:29:34 AM
not good. .
February 26, 2016, 10:00:16 AM
This one seems to be on testnet or something. Says 50BTC block reward, and it was just started on 2/23 as you can see in the stats.
If there's no contact to be found, one could try to reach the miner(s) via tiny BTC payment with a message attached.
February 26, 2016, 09:33:55 AM
http://61.219.120.109:9332/static/ - 50 TH - P2Pool version: 14.0-6 (probably protocol 15?)
http://80.74.153.50:9332/static/ - 563 GH - P2Pool version: 13.4-67
http://104.238.174.252:9332/static/ - 769 GH - P2Pool version: 13.4-67 (probably protocol 15?)
http://80.64.65.87:9332/static/ - 543 GH - P2Pool version: 14.0-13 (show pool rate 300TH....it is possible that 300 th they are at version 14?)
Yea, it's a bummer, that bottom node was restarted 9 days ago, must be automated.
It's IP is hosted in Hungary by Internet4U, but aside from an abuse email for the full IP block I'm not able to find any contact info...
https://apps.db.ripe.net/search/query.html 80.64.65.87
It is possible that we left 300TH behind in the last hard fork, but I can't see how that many folks would mine away for that long without noticing, seems crazy to me....
Edit: #1 & #3 are running protocol 15, you can visit the /local_stats endpoint to see
February 26, 2016, 04:10:26 AM
http://61.219.120.109:9332/static/ - 50 TH - P2Pool version: 14.0-6 (probably protocol 15?)
http://80.74.153.50:9332/static/ - 563 GH - P2Pool version: 13.4-67
http://104.238.174.252:9332/static/ - 769 GH - P2Pool version: 13.4-67 (probably protocol 15?)
http://80.64.65.87:9332/static/ - 543 GH - P2Pool version: 14.0-13 (show pool rate 300TH....it is possible that 300 th they are at version 14?)
February 25, 2016, 05:18:20 AM
The administrator of p2pool.co he answer to your emails?
I wrote a mail last week. No answer.
February 25, 2016, 01:11:54 AM
The administrator of p2pool.co he answer to your emails?
From December to me no longer responds and I should update my node addresses...you know a way to contact him?
thank you and ....sorry for OT
From December to me no longer responds and I should update my node addresses...you know a way to contact him?
thank you and ....sorry for OT
February 24, 2016, 07:51:34 PM
I've now been running 24 hours with the latest git version & all seems good. The error message seems to have stopped & efficiency is back to normal again.
Good stuff.
Good stuff.
February 23, 2016, 03:18:11 PM
so where is P2Pool heading? 8 days expected to find a block.. shouldn't we at least remove the "pay only the last 3 days" part? and make sidechain with longer block time ( less work restarts, longer chain )..
so PPLNS could average over the last 30 days or so?
so PPLNS could average over the last 30 days or so?
If there is a hardfork necessary to support >1M blocks, that would definitely be the right time to do something about this.
At the moment, when mining with p2pool you're essentially betting on the pool to find a block in the next three days, which is roughly 30%. Otherwise your hashrate is completely wasted, isn't it?
Plenty of hashrate is wasted anyway. It means it isn't counted as part of your share though. If your percentage of the pool hashrate remains fairly constant, it won't really make much difference.
February 23, 2016, 01:43:41 PM
so where is P2Pool heading? 8 days expected to find a block.. shouldn't we at least remove the "pay only the last 3 days" part? and make sidechain with longer block time ( less work restarts, longer chain )..
so PPLNS could average over the last 30 days or so?
so PPLNS could average over the last 30 days or so?
If there is a hardfork necessary to support >1M blocks, that would definitely be the right time to do something about this.
At the moment, when mining with p2pool you're essentially betting on the pool to find a block in the next three days, which is roughly 30%. Otherwise your hashrate is completely wasted, isn't it?
February 23, 2016, 12:32:35 PM
http://minefast.coincadence.com/p2pool-stats.php
Forrest controls p2pool.info, that's up to him.
I've been considering moving the stats over to P2Pool.org, that would fix the search rankings...
Forrest controls p2pool.info, that's up to him.
I've been considering moving the stats over to P2Pool.org, that would fix the search rankings...
Bookmarked, thanks.
If people can link to that page from elsewhere, that should also increase the search rankings. So remember to do it when you get the chance
February 23, 2016, 12:29:09 PM
When I search for "p2pool blocks", I still get the seriously out-of-date p2pool.info page. I know there is a more accurate one out there but it doesn't appear to show in the search results. Any ideas on what we can do to either get p2pool fixed or disabled with a redirect and/or get the other page promoted in the search rankings?
http://minefast.coincadence.com/p2pool-stats.php
Forrest controls p2pool.info, that's up to him.
I've been considering moving the stats over to P2Pool.org, that would fix the search rankings...
February 23, 2016, 12:23:08 PM
When I search for "p2pool blocks", I still get the seriously out-of-date p2pool.info page. I know there is a more accurate one out there but it doesn't appear to show in the search results. Any ideas on what we can do to either get p2pool fixed or disabled with a redirect and/or get the other page promoted in the search rankings? The defunct page is also cited in the first post in this thread (paging forrestv)
I wouldn't be surprised if this page has been fairly damaging to p2pool to be honest.
I wouldn't be surprised if this page has been fairly damaging to p2pool to be honest.
February 23, 2016, 12:15:23 PM
Hmm... not much good using a fork designed to increase the max blocksize limit if you can't... increase the max blocksize.
It's a p2pool bug, not a Classic bug.
You can increase the max block size limit, just not the soft limit when mining with p2pool.
You overlooked that these are two different things in your urgent need to snark.
February 23, 2016, 12:12:10 PM
So, if you have not heard yet there is another serious vulnerability for anyone running Unix based machines.
A severe vulnerability in the Gnu C Library's DNS client has been discovered and it affects just about EVERY bitcoin implementation.
Info here: http://linux.slashdot.org/story/16/02/16/1724222/red-hat-google-disclose-severe-glibc-dns-vulnerability-patched-but-widespread
Patches are available, but you must update.
For Debian/Ubuntu:
Code:
sudo apt-get update && sudo apt-get upgrade && sudo reboot
The reboot is important.
Looks like Slackware is immune. Woot!
http://www.linuxquestions.org/questions/slackware-14/glibc-security-patch-cve-2015-7547-a-4175572402/
February 23, 2016, 11:45:37 AM
so where is P2Pool heading? 8 days expected to find a block.. shouldn't we at least remove the "pay only the last 3 days" part? and make sidechain with longer block time ( less work restarts, longer chain )..
so PPLNS could average over the last 30 days or so?
so PPLNS could average over the last 30 days or so?
February 23, 2016, 08:04:36 AM
I've been in contact with forrestv on github, if anyone else who is having this problem can send him their log file he would appreciate it. There is a "tentative" fix available on git but I'm unable to test it atm, so if anyone can try it & provide feedback, that will also help forrestv out.
if you want you can try "test.warp2pool.eu:9332" I'm doing a test with the latest version p2pool and bitcoin classic (0.11.2).
February 22, 2016, 10:59:42 PM
Regarding this:
I've been in contact with forrestv on github, if anyone else who is having this problem can send him their log file he would appreciate it. There is a "tentative" fix available on git but I'm unable to test it atm, so if anyone can try it & provide feedback, that will also help forrestv out.
There appears to be an issue with p2pool producing lots of orphaned shares if the blocksize is greater than about 750 kB. This is caused by the limit on the number of transactions per share being too low.
https://github.com/p2pool/p2pool/issues/274
https://github.com/p2pool/p2pool/issues/274
I've been in contact with forrestv on github, if anyone else who is having this problem can send him their log file he would appreciate it. There is a "tentative" fix available on git but I'm unable to test it atm, so if anyone can try it & provide feedback, that will also help forrestv out.
February 22, 2016, 11:24:11 AM
Ah, I see where you're coming from - could be so. It would be nice if forrestv chimes in with his thoughts/ideas about the upcoming blocksize increase & what aterations are needed for p2pool to take advantage of it though.
+1
You know how the efficiency is calculated? On my public node changes efficiency (up and down) even without sending share..
Also, it is possible that some miners with high ping connect to my node and their decrease the node efficiency?
ps: sorry for my bad english...
https://github.com/p2pool/p2pool/blob/master/p2pool/web.py#L165
Code:
efficiency=(1 - (stale_orphan_shares+stale_doa_shares)/shares)/(1 - global_stale_prop) if shares else None,
It will change without you submitting a share based on global pool efficiency.
If there is more than 1 miner on your node then it's really not a relevant number to you specifically. All that matters is your miners efficiency as compared with the pool as a whole.
February 22, 2016, 10:22:30 AM
Ah, I see where you're coming from - could be so. It would be nice if forrestv chimes in with his thoughts/ideas about the upcoming blocksize increase & what aterations are needed for p2pool to take advantage of it though.
+1
You know how the efficiency is calculated? On my public node changes efficiency (up and down) even without sending share..
Also, it is possible that some miners with high ping connect to my node and their decrease the node efficiency?
ps: sorry for my bad english...
February 22, 2016, 10:20:03 AM
Sorry, but IMHO forrest was referring to tampering with the p2pool settings, namely
Ah, I see where you're coming from - could be so. It would be nice if forrestv chimes in with his thoughts/ideas about the upcoming blocksize increase & what aterations are needed for p2pool to take advantage of it though.
If max block size is increased it will require a hard fork of P2Pool (not nearly as big of a deal as a Bitcoin HF, we did 2 in the last year), not much to do about it now as any block > 1MB will be rejected by the network.
Jump to: