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

[jedimstr]

Peer =148.251.238.178:18702 is causing bitcoind to go out of sync, 0 hours behind..... lying about blocks

Is there a way to block these getaddr.bitnodes.io:0.1 clients from bitcoind, or do one have to block ip after ip from firewall?

Not sure but, it seems to cause orphan and dead shares while this happens..0 hours behind....

As far as I know, you can only block them by setting up a whitelist of connections to use, so only setting up connections for specific peers. 
Use "connect" to establish a list of trusted peers, but then you're only locked to those peers which has its pros and cons.

-addnode=<ip>          Add a node to connect to and attempt to keep the connection open
 -connect=<ip>          Connect only to the specified node(s)
 -seednode=<ip>         Connect to a node to retrieve peer addresses, and disconnect
 -externalip=<ip>       Specify your own public address
 -onlynet=<net>         Only connect to nodes in network <net> (IPv4, IPv6 or Tor)

-connect method would be nice if I only knew how to connect to p2pool node, not sure what happens if bitcoind is started up witout connect settings and then p2pool brought up - then change the config to connect=specified hosts and reboot bitcoind.

It can be that if a block is found it cant be submitted to bitcoind..

Installed and configured iptables and now it stays synced..

I think the connect param only applies to peer connections, not RPC connections from the same machine. Worst case scenario, you could allow 127.0.0.1 (which is localhost).

[1713306577]

1713306577

[1713306577]

1713306577

[1713306577]

1713306577

[1713306577]

1713306577

[mdude77]

The good news:
I managed to make a stratum proxy that works with p2pool.

The bad news:
It looks to me like the S2s can't respond quick enough to the restarts from p2pool.  That causes rejects.  If the difficulty is too low, it gets out of hand, where the shares coming from the S2s are from prior jobIDs, as many as two or three back.

I'm watching the data flow through real time, and shares submitted 1-5 seconds after the restart request (with the new jobID) are rejected because the jobID is the wrong one.

Other things of note:
- It'd be useful if p2pool returned some indication as to what was wrong when an item is rejected.  I'm going to have to track jobIDs myself to visually indicate if it was rejected because of a bad jobid.
- The "id" in the response from p2pool doesn't match the "id" from the sender.  The stratum specs are a bit vague, but it seems to me the response "id" should be the same as the sender id.  Instead it seems to be an incremental number for that connection.

More to come.

M

[mdude77]

I'm watching my ants go through my proxy to Eligius now.

Two big things that are different between Eligius and p2pool:

- when Eligius sends the "new job info", in most cases it doesn't tell the miner to restart the work (p2pool does all the time)
- the Ants still take a while to switch over to the new "job id".  However Eligius accepts the work from old jobids anyhow (p2pool rejects them all the time)

M

[sconklin321]

The good news:
I managed to make a stratum proxy that works with p2pool.

The bad news:
It looks to me like the S2s can't respond quick enough to the restarts from p2pool.  That causes rejects.  If the difficulty is too low, it gets out of hand, where the shares coming from the S2s are from prior jobIDs, as many as two or three back.

I'm watching the data flow through real time, and shares submitted 1-5 seconds after the restart request (with the new jobID) are rejected because the jobID is the wrong one.

Other things of note:
- It'd be useful if p2pool returned some indication as to what was wrong when an item is rejected.  I'm going to have to track jobIDs myself to visually indicate if it was rejected because of a bad jobid.
- The "id" in the response from p2pool doesn't match the "id" from the sender.  The stratum specs are a bit vague, but it seems to me the response "id" should be the same as the sender id.  Instead it seems to be an incremental number for that connection.

More to come.

M

I know this is used for scrypt and not btc, but could this be solved by setting up a sub pool like doge.st has setup.  They run a stratum to stratum proxy that, if I get how it works correctly, splits the stratum work up and then distributes it to he miners looking for smaller shares.  Here is the link to their proxypool server:

https://github.com/dogestreet/proxypool

I'm not sure if this works outside of scrypt based coins as I don't know the inner workings of the protocols involved, but I do know that, if I remember correctly, the doge p2pool is set on 10 or 15 second share times so it should be requesting new work faster and more frequently that our p2pool does.  Just an idea I had to through out, I'd test it, but I don't have an S2 to test it with.  If it does work for the S2, I wonder if it would work with the bitfury stuff that is preventing Petamine from mining with P2Pool.

Edit:  Just read the readme and it only works with scrypt upstream servers, but maybe it's something worth forking if someone knows how to get it working.

[nreal]

Pool Luck(?) (7 days, 30 days, 90 days): 185.7%102.4%98.9%

[nreal]

The good news:
I managed to make a stratum proxy that works with p2pool.

The bad news:
It looks to me like the S2s can't respond quick enough to the restarts from p2pool.  That causes rejects.  If the difficulty is too low, it gets out of hand, where the shares coming from the S2s are from prior jobIDs, as many as two or three back.

I'm watching the data flow through real time, and shares submitted 1-5 seconds after the restart request (with the new jobID) are rejected because the jobID is the wrong one.

Other things of note:
- It'd be useful if p2pool returned some indication as to what was wrong when an item is rejected.  I'm going to have to track jobIDs myself to visually indicate if it was rejected because of a bad jobid.
- The "id" in the response from p2pool doesn't match the "id" from the sender.  The stratum specs are a bit vague, but it seems to me the response "id" should be the same as the sender id.  Instead it seems to be an incremental number for that connection.

More to come.

M

So it works like a charm with walletadress/10000000+1024 ?

And without those 30s altcoins..

[mdude77]

The good news:
I managed to make a stratum proxy that works with p2pool.

The bad news:
It looks to me like the S2s can't respond quick enough to the restarts from p2pool.  That causes rejects.  If the difficulty is too low, it gets out of hand, where the shares coming from the S2s are from prior jobIDs, as many as two or three back.

I'm watching the data flow through real time, and shares submitted 1-5 seconds after the restart request (with the new jobID) are rejected because the jobID is the wrong one.

Other things of note:
- It'd be useful if p2pool returned some indication as to what was wrong when an item is rejected.  I'm going to have to track jobIDs myself to visually indicate if it was rejected because of a bad jobid.
- The "id" in the response from p2pool doesn't match the "id" from the sender.  The stratum specs are a bit vague, but it seems to me the response "id" should be the same as the sender id.  Instead it seems to be an incremental number for that connection.

More to come.

M

So it works like a charm with walletadress/10000000+1024 ?

And without those 30s altcoins..

I'm not sure if 512 or 1024 works best.  Overall, while a proxy definitely helps, the fundamental issue appears to be:

1 - the Ants can't change work fast enough to keep up with the constant changing of job IDs from p2pool
2 - p2pool doesn't accept work with old job IDs.  ever.

Eligius does submit a new job ids roughly 30-50 seconds, but it usually doesn't tell the Ants to drop what they're doing and restart "clean_jobs == false".

So I'd say either Bitmain needs to improve the response time on the Ants.. or p2pool needs to stop telling the workers to drop their work and start fresh every 30-40 seconds.

M

[nreal]

The good news:
I managed to make a stratum proxy that works with p2pool.

The bad news:
It looks to me like the S2s can't respond quick enough to the restarts from p2pool.  That causes rejects.  If the difficulty is too low, it gets out of hand, where the shares coming from the S2s are from prior jobIDs, as many as two or three back.

I'm watching the data flow through real time, and shares submitted 1-5 seconds after the restart request (with the new jobID) are rejected because the jobID is the wrong one.

Other things of note:
- It'd be useful if p2pool returned some indication as to what was wrong when an item is rejected.  I'm going to have to track jobIDs myself to visually indicate if it was rejected because of a bad jobid.
- The "id" in the response from p2pool doesn't match the "id" from the sender.  The stratum specs are a bit vague, but it seems to me the response "id" should be the same as the sender id.  Instead it seems to be an incremental number for that connection.

More to come.

M

So it works like a charm with walletadress/10000000+1024 ?

And without those 30s altcoins..

What does graphs tell, hourly? Is it hashing below 1th?

I'm not sure if 512 or 1024 works best.  Overall, while a proxy definitely helps, the fundamental issue appears to be:

1 - the Ants can't change work fast enough to keep up with the constant changing of job IDs from p2pool
2 - p2pool doesn't accept work with old job IDs.  ever.

Eligius does submit a new job ids roughly 30-50 seconds, but it usually doesn't tell the Ants to drop what they're doing and restart "clean_jobs == false".

So I'd say either Bitmain needs to improve the response time on the Ants.. or p2pool needs to stop telling the workers to drop their work and start fresh every 30-40 seconds.

M

[nreal]

The good news:
I managed to make a stratum proxy that works with p2pool.

The bad news:
It looks to me like the S2s can't respond quick enough to the restarts from p2pool.  That causes rejects.  If the difficulty is too low, it gets out of hand, where the shares coming from the S2s are from prior jobIDs, as many as two or three back.

I'm watching the data flow through real time, and shares submitted 1-5 seconds after the restart request (with the new jobID) are rejected because the jobID is the wrong one.

Other things of note:
- It'd be useful if p2pool returned some indication as to what was wrong when an item is rejected.  I'm going to have to track jobIDs myself to visually indicate if it was rejected because of a bad jobid.
- The "id" in the response from p2pool doesn't match the "id" from the sender.  The stratum specs are a bit vague, but it seems to me the response "id" should be the same as the sender id.  Instead it seems to be an incremental number for that connection.

More to come.

M

So it works like a charm with walletadress/10000000+1024 ?

And without those 30s altcoins..

What does graphs tell, hourly? Is it hashing below 1th?

I'm not sure if 512 or 1024 works best.  Overall, while a proxy definitely helps, the fundamental issue appears to be:

1 - the Ants can't change work fast enough to keep up with the constant changing of job IDs from p2pool
2 - p2pool doesn't accept work with old job IDs.  ever.

Eligius does submit a new job ids roughly 30-50 seconds, but it usually doesn't tell the Ants to drop what they're doing and restart "clean_jobs == false".

So I'd say either Bitmain needs to improve the response time on the Ants.. or p2pool needs to stop telling the workers to drop their work and start fresh every 30-40 seconds.

M

So its below 1th in http://127.0.0.1:9332/static/graphs.html?Hour ?

[mdude77]

So its below 1th in http://127.0.0.1:9332/static/graphs.html?Hour ?

It's close to 1th/s.  The problem is the reject level is too high.

What I don't understand is why it appears so different when using a proxy.  The reject level is high enough to make the effective rash rate what's showing when you connect directly.  But through the proxy is shows the reject count.

M

[nreal]

So its below 1th in http://127.0.0.1:9332/static/graphs.html?Hour ?

It's close to 1th/s.  The problem is the reject level is too high.

What I don't understand is why it appears so different when using a proxy.  The reject level is high enough to make the effective rash rate what's showing when you connect directly.  But through the proxy is shows the reject count.

M

Isnt the DOA the same thing?

[mdude77]

So its below 1th in http://127.0.0.1:9332/static/graphs.html?Hour ?

It's close to 1th/s.  The problem is the reject level is too high.

What I don't understand is why it appears so different when using a proxy.  The reject level is high enough to make the effective rash rate what's showing when you connect directly.  But through the proxy is shows the reject count.

M

Isnt the DOA the same thing?

Yes.  I think the problem is p2pool isn't properly feeding the reject back to cgminer, so cgminer isn't counting the rejects.

It also looks like the Ants have problems changing difficulty quickly.  The lower the difficulty was set to, the longer it takes to change.  That causes boatloads of "worker submitted hash > target" messages.  That message itself is misleading, it's actually hash < target the way you and I think about it.  But in bitcoin world, it's > target.

M

[mdude77]

I found a hack that might get my proxy to work S2s and p2pool.

I always set the jobid in the work submitted to the current jobid.  p2pool doesn't seem to mind.  It rejects one or two every so often, but that's it.

I need someone who knows p2pool or cgminer better than I do to see if that's legit or not.

M

[PatMan]

Very interesting mdude - maybe drop kano a line? He'd know. It's all a bit above me I'm afraid.......

[nreal]

P2pool expected sharetime should be higher than 30s..

[mdude77]

At the moment my conclusion is a proxy isn't going to help getting S2s working with p2pool.

I believe the problem is the constant "drop EVERYTHING you are doing and restart" messages that p2pool sends every 30 seconds.  Then it rejects all the old work coming p2pool leading to large DOA.

My recommendations for p2pool to become more S2 friendly:

1 - Sending new work every 30 seconds is fine.  It's apparently not necessary to force the miner to restart "clean jobs" = true.  It also needs to gracefully accept work from prior job IDs for a period of time like other pools do.

2 - Start at a higher pseudo difficulty than 1.

3 - Allow a higher pseudo difficulty than 1000.

4 - Send the actual errors back for rejected work, instead of just "false".


If I understood python I'd take a stab at 2 through 4.  1 might be a big deal.

M

[ceslick]

I have 4 S1's with kano's update applied, what other asic's would be recommended for p2pool?

[windpath]

I have 4 S1's with kano's update applied, what other asic's would be recommended for p2pool?

I'd suggest this list is incomplete at best, but its a start: https://en.bitcoin.it/wiki/P2Pool#Interoperability_table

SP10 needs to be added.

[windpath]

At the moment my conclusion is a proxy isn't going to help getting S2s working with p2pool.

I believe the problem is the constant "drop EVERYTHING you are doing and restart" messages that p2pool sends every 30 seconds.  Then it rejects all the old work coming p2pool leading to large DOA.

My recommendations for p2pool to become more S2 friendly:

1 - Sending new work every 30 seconds is fine.  It's apparently not necessary to force the miner to restart "clean jobs" = true.  It also needs to gracefully accept work from prior job IDs for a period of time like other pools do.

2 - Start at a higher pseudo difficulty than 1.

3 - Allow a higher pseudo difficulty than 1000.

4 - Send the actual errors back for rejected work, instead of just "false".


If I understood python I'd take a stab at 2 through 4.  1 might be a big deal.

M

Dude, GREAT WORK!

I'd suggest that perhaps Bitmain or Kano could probably fix the Ants. Bitmain because they should, Kano because he's awesome

From your findings it sounds like fixing the ants so they reply to work restarts properly would fix the problem:

I believe the problem is the constant "drop EVERYTHING you are doing and restart" messages that p2pool sends every 30 seconds.

The more frequent work restarts are a direct result of p2pools higher share rate...

I found a hack that might get my proxy to work S2s and p2pool. I always set the jobid in the work submitted to the current jobid

I'm not sure of the impact this may have, I would think it would break the share header?

From the wiki:

P2Pool shares form a "sharechain" with each share referencing the previous share's hash. Each share contains a standard Bitcoin block header, some P2Pool-specific data that is used to compute the generation transaction (total subsidy, payout script of this share, a nonce, the previous share's hash, and the current target for shares), and a Merkle branch linking that generation transaction to the block header's Merkle hash.

but if it works it sounds like a good short term solution

[mdude77]

I'd suggest that perhaps Bitmain or Kano could probably fix the Ants. Bitmain because they should, Kano because he's awesome

From your findings it sounds like fixing the ants so they reply to work restarts properly would fix the problem:

I believe the problem is the constant "drop EVERYTHING you are doing and restart" messages that p2pool sends every 30 seconds.

The more frequent work restarts are a direct result of p2pools higher share rate...

The problem is the Ants are hardware.  There's a finite amount of stuff that can be done to them through software.  If it's a hardware issue, then I'd be surprised if the S3s work with p2pool.  If it's software, I don't understand why Bitmain hasn't fixed it.  Surely they could do what I did to see what's going on.

I found a hack that might get my proxy to work S2s and p2pool. I always set the jobid in the work submitted to the current jobid

I'm not sure of the impact this may have, I would think it would break the share header?

Doing that fixed the absurd amount of rejects I was getting.  However I still had the decreased hashrate problem.  Because of the current true share size, my 2.2th/s would take an average of 2 hours to find a share.  I didn't let it chug long enough to see if I regularly found shares, or if I got a larger than average amount of dead shares.  I'm not going to throw away a day of mining to experiment with it.

M