Pages:
Author

Topic: BiblePay - TestNet Thread - Pool Testing for Proof of Bible Hash Pool (PoBh) - page 3. (Read 13230 times)

full member
Activity: 221
Merit: 100
I'm not sure why DDoS would be effective either, except for the idea that if the pool gets knocked off right before the solution is found, then all the hashes for that block from the pool are wasted.  Granted, I would think that would require someone to be paying attention to the block chain pretty fiercely but that doesn't really make much sense.  The only other thing that makes a bit more sense is a campaign of a hacker who has an axe to grind with religion but really, if that were the case (not suggesting or condoning this) why wouldn't they hit some high profile target like Joel Osteen or The 700 Club.  So really, the only thing that makes much sense is a rival coin, which is sad to think about, or someone that doesn't realize no pool all that hash goes solo (and for the short term, that's a zero sum game, maybe long range the lack of a pool drives out other miners, but that's a bit hard to fathom).

We need more pool servers, I've offered as well to buy and run one if the price wasn't outlandish but I think the Dev wants to get a more finished product out there before that sort of thing happens.  The counter argument to that is if there were one or two or three other supporters (I won't name anyone at the risk of offending, but I'd wager there's five or six posters in this thread contributing half the posts), like myself, that were willing to buy or at least Co-Lo a pool server under the direction of the Dev with the understanding it would be remotely accessed and upgraded on the short term by him and after his pool software was "prime time", would then become the hosts duty, there would be enough takers.
I can tell you with relative certainty why we're getting ddossed.  Anyone who tries to create a 'novel' algorithm and a new pool is a threat to the top 50 coins on coinmarketcap.  I think its more of a jealous group or actor than someone trying to extract an edge out of the pool. 

On forking the code and running multiple pools, I agree, it is probably better to give you an early version of the code and have more than one, and have you upgrade later, rather than wait until we have a finished pool.  However, I dont view it as 'ready' to check in.  It still needs a couple things related to SQL, so, if you can respect the fact that its not ready to check in yet, thats why its too early to fork it to two beta pools.  In addition, the alpha version is 65% complete (keeps getting interrupted by these outages) and I may end up checking that in instead, depending on how its received.  The alpha version is completely different than the beta version.





there are ready VPSs or dedicated servers with DDOS protection on the market..  did you consider using one or few of them ?

google cloud is available for free now and it has DDOs protection too
full member
Activity: 406
Merit: 101
I can tell you with relative certainty why we're getting ddossed.  Anyone who tries to create a 'novel' algorithm and a new pool is a threat to the top 50 coins on coinmarketcap.  I think its more of a jealous group or actor than someone trying to extract an edge out of the pool.  

On forking the code and running multiple pools, I agree, it is probably better to give you an early version of the code and have more than one, and have you upgrade later, rather than wait until we have a finished pool.  However, I dont view it as 'ready' to check in.  It still needs a couple things related to SQL, so, if you can respect the fact that its not ready to check in yet, thats why its too early to fork it to two beta pools.  In addition, the alpha version is 65% complete (keeps getting interrupted by these outages) and I may end up checking that in instead, depending on how its received.  The alpha version is completely different than the beta version.


No I understand adding another chunk of code to babysit is an issue, I'm a huge fan of this coin as evidenced by my postings and there are several others that have faith in a coin with a Dev that has something unique but isn't shouting from the mountains "Look how awesome I am" or "Buy buy buy while it's cheap so I can sell my pre-stake".   You've been the most humble Dev I've seen in quite a while, you work tirelessly and you deserve kudos.  There are plenty of us who are willing to help you just need to let us know when.  One of the things is hosting another pool or two, run on the same terms and same config as yours while the pool development grows.
full member
Activity: 406
Merit: 101
So I dont want to release this for general consumption yet, but with the pool being in the state it is I really want to get a jump start on making it more reliable.

So, the new version is out at biblepay.org, this is targeted to all pool miners who will test this version in Prod.
Version 1.0.2.6:

- Combine communications from all threads to one packet
- Fix inconsistent switching between Pool health down, and solo mining (into 5 minute blocks)
- Fix inconsistent POOL_DOWN messages in miner

Lets please get at least 10-20 testers out on this version, test against PROD, and see if things improve.
Then we will release on the main forum if its working correctly.

Thanks.

PS I just upgraded two of my nodes, and pre-tested this release and so far, its good.


I put two nodes on it, my desktop is running just genproc 2 until I turn it up to full power when I'm not using it, and my laptop is being picky about it for some reason, but I'm retrying a few things there.  Right now it seems the pool is down according to getmininginfo, but I'll leave them running all day in pool mode and let you know what happens.
full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
I'm not sure why DDoS would be effective either, except for the idea that if the pool gets knocked off right before the solution is found, then all the hashes for that block from the pool are wasted.  Granted, I would think that would require someone to be paying attention to the block chain pretty fiercely but that doesn't really make much sense.  The only other thing that makes a bit more sense is a campaign of a hacker who has an axe to grind with religion but really, if that were the case (not suggesting or condoning this) why wouldn't they hit some high profile target like Joel Osteen or The 700 Club.  So really, the only thing that makes much sense is a rival coin, which is sad to think about, or someone that doesn't realize no pool all that hash goes solo (and for the short term, that's a zero sum game, maybe long range the lack of a pool drives out other miners, but that's a bit hard to fathom).

We need more pool servers, I've offered as well to buy and run one if the price wasn't outlandish but I think the Dev wants to get a more finished product out there before that sort of thing happens.  The counter argument to that is if there were one or two or three other supporters (I won't name anyone at the risk of offending, but I'd wager there's five or six posters in this thread contributing half the posts), like myself, that were willing to buy or at least Co-Lo a pool server under the direction of the Dev with the understanding it would be remotely accessed and upgraded on the short term by him and after his pool software was "prime time", would then become the hosts duty, there would be enough takers.
I can tell you with relative certainty why we're getting ddossed.  Anyone who tries to create a 'novel' algorithm and a new pool is a threat to the top 50 coins on coinmarketcap.  I think its more of a jealous group or actor than someone trying to extract an edge out of the pool.  

On forking the code and running multiple pools, I agree, it is probably better to give you an early version of the code and have more than one, and have you upgrade later, rather than wait until we have a finished pool.  However, I dont view it as 'ready' to check in.  It still needs a couple things related to SQL, so, if you can respect the fact that its not ready to check in yet, thats why its too early to fork it to two beta pools.  In addition, the alpha version is 65% complete (keeps getting interrupted by these outages) and I may end up checking that in instead, depending on how its received.  The alpha version is completely different than the beta version.


full member
Activity: 221
Merit: 100
So I dont want to release this for general consumption yet, but with the pool being in the state it is I really want to get a jump start on making it more reliable.

So, the new version is out at biblepay.org, this is targeted to all pool miners who will test this version in Prod.
Version 1.0.2.6:

- Combine communications from all threads to one packet
- Fix inconsistent switching between Pool health down, and solo mining (into 5 minute blocks)
- Fix inconsistent POOL_DOWN messages in miner


Lets please get at least 10-20 testers out on this version, test against PROD, and see if things improve.
Then we will release on the main forum if its working correctly.

Thanks.

PS I just upgraded two of my nodes, and pre-tested this release and so far, its good.


started 1.0.2.6 on my laptop with pool config.
 
showing   "poolmining": false


12:25:40

{
  "blocks": 5537,
  "currentblocksize": 1000,
  "currentblocktx": 0,
  "difficulty": 0.03644124382553488,
  "errors": "",
  "genproclimit": 4,
  "networkhashps": 267018.6290590712,
  "hashps": 46101.79029932116,
  "minerstarttime": "08-31-2017 16:24:43",
  "pooledtx": 0,
  "testnet": false,
  "chain": "main",
  "biblepay-generate": true,
  "poolinfo1": "",
  "poolinfo2": "",
  "poolinfo3": "",
  "miningpulse": 80,
  "poolmining": false
}
full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
So I dont want to release this for general consumption yet, but with the pool being in the state it is I really want to get a jump start on making it more reliable.

So, the new version is out at biblepay.org, this is targeted to all pool miners who will test this version in Prod.
Version 1.0.2.6:

- Combine communications from all threads to one packet
- Fix inconsistent switching between Pool health down, and solo mining (into 5 minute blocks)
- Fix inconsistent POOL_DOWN messages in miner


Lets please get at least 10-20 testers out on this version, test against PROD, and see if things improve.
Then we will release on the main forum if its working correctly.

Thanks.

PS I just upgraded two of my nodes, and pre-tested this release and so far, its good.
full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
This site can’t be reached

pool.biblepay.org’s server DNS address could not be found.
Search Google for pool biblepay org
ERR_NAME_NOT_RESOLVED

ping pool.biblepay.org
Ping request could not find host pool.biblepay.org. Please check the name and try again.




ping biblepay.org

Pinging biblepay.org [104.25.250.110] with 32 bytes of data:
Reply from 104.25.250.110: bytes=32 time=35ms TTL=53
Reply from 104.25.250.110: bytes=32 time=26ms TTL=53
Reply from 104.25.250.110: bytes=32 time=29ms TTL=53
Reply from 104.25.250.110: bytes=32 time=26ms TTL=53

Ping statistics for 104.25.250.110:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 26ms, Maximum = 35ms, Average = 29ms

Looks like cloudflare is starting up, but not entirely yet, let me check into this.
full member
Activity: 221
Merit: 100
This site can’t be reached

pool.biblepay.org’s server DNS address could not be found.
Search Google for pool biblepay org
ERR_NAME_NOT_RESOLVED

ping pool.biblepay.org
Ping request could not find host pool.biblepay.org. Please check the name and try again.




ping biblepay.org

Pinging biblepay.org [104.25.250.110] with 32 bytes of data:
Reply from 104.25.250.110: bytes=32 time=35ms TTL=53
Reply from 104.25.250.110: bytes=32 time=26ms TTL=53
Reply from 104.25.250.110: bytes=32 time=29ms TTL=53
Reply from 104.25.250.110: bytes=32 time=26ms TTL=53

Ping statistics for 104.25.250.110:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 26ms, Maximum = 35ms, Average = 29ms
full member
Activity: 462
Merit: 103
Great news! Every one of those three improvements should boost performance by a few times, and then when you multiply all three... Smiley
full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
Just to let you all know Im committed to fixing the pool and still working behind the scenes to make it reliable.

I am enabling cloudflare next, as it appears the anti-ddos software I am using is not industrial strength enough to handle the load, and in addition, the IPs keep changing so its impossible to block them.

Also, I will be moving the database to higher performance raid this afternoon, I will update when that takes place.

Finally, a new version is almost ready, with the ability to combine all of the communication packets for any number of threads into one.  This should be exciting to test, and should give us a performance boost.  Ill update as soon as its ready.

full member
Activity: 462
Merit: 103
is it possible to use multiple machines to solo mine in a single wallet i.e. sort of combine hashpower ? 

Yes, just copy the encrypted wallet.dat file to each machine. That way I only had the wallet running in the taskbar on my home PC (not mining) and I got notifications when one of the remote machines found a block. Smiley

does it mean hashrate will be really combined or every PC will keep mining separately just sending results into the same address ? 

They are mining separately and send to the same wallet (not address), but compared to one monster PC which for its hashrate has the sum of your multiple PCs, there's no difference in probability of finding a block.
full member
Activity: 221
Merit: 100
is it possible to use multiple machines to solo mine in a single wallet i.e. sort of combine hashpower ? 

Yes, just copy the encrypted wallet.dat file to each machine. That way I only had the wallet running in the taskbar on my home PC (not mining) and I got notifications when one of the remote machines found a block. Smiley

does it mean hashrate will be really combined or every PC will keep mining separately just sending results into the same address ? 
full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
Does getting pool down errors still massively slow down miner performance? If miners smoothly revert to solo mining when the pool goes down with no significant drop in performance then the hit to the network hashrate would be low and there would be no motivation to DDoS (not that that'd necessarily stop them).

Of course it affects solo mining performance, my machines go to full CPU usage and hash rate only when there is no pool parameter in the conf file. Otherwise, they are either about 60% hash rate, or just showing 100% but CPU is constantly going up and down and doesn't get a full utilization, not even for 10 seconds, while on solo it's very steady.

You can also observe that everyone's shares in the leaderboard have dropped significantly compared to the times when pool mining was steady. I suggested it was DoS 3 days ago but it was dismissed.

It wasn't dismissed.

EDIT:
To Happys point: the software IS designed to solo mine when the pool is down.  The important thing about the feature is: Its supposed to solo mine for a good chunk of time, ie 5 minutes, while it is determined that it is in solo mode.  That would give you a consistent hash rate when the pool is down.  If the feature is fluctuating, it is malfunctioning.  That means that a ticket needs to be put in on github describing the problem.

hero member
Activity: 714
Merit: 500
Does getting pool down errors still massively slow down miner performance? If miners smoothly revert to solo mining when the pool goes down with no significant drop in performance then the hit to the network hashrate would be low and there would be no motivation to DDoS (not that that'd necessarily stop them).

Of course it affects solo mining performance, my machines go to full CPU usage and hash rate only when there is no pool parameter in the conf file. Otherwise, they are either about 60% hash rate, or just showing 100% but CPU is constantly going up and down and doesn't get a full utilization, not even for 10 seconds, while on solo it's very steady.

You can also observe that everyone's shares in the leaderboard have dropped significantly compared to the times when pool mining was steady. I suggested it was DoS 3 days ago but it was dismissed.

Wow, just read last few pages of this thread and realized that pool has been DDOSed. No wonder the connection to pool is unstable and hashrate was drifting up and down recently, and some of my mining machine had 0 hashrate sometimes...
full member
Activity: 462
Merit: 103
Does getting pool down errors still massively slow down miner performance? If miners smoothly revert to solo mining when the pool goes down with no significant drop in performance then the hit to the network hashrate would be low and there would be no motivation to DDoS (not that that'd necessarily stop them).

Of course it affects solo mining performance, my machines go to full CPU usage and hash rate only when there is no pool parameter in the conf file. Otherwise, they are either about 60% hash rate, or just showing 100% but CPU is constantly going up and down and doesn't get a full utilization, not even for 10 seconds, while on solo it's very steady.

You can also observe that everyone's shares in the leaderboard have dropped significantly compared to the times when pool mining was steady. I suggested it was DoS 3 days ago but it was dismissed.
full member
Activity: 406
Merit: 101
I'm not sure why DDoS would be effective either, except for the idea that if the pool gets knocked off right before the solution is found, then all the hashes for that block from the pool are wasted.  Granted, I would think that would require someone to be paying attention to the block chain pretty fiercely but that doesn't really make much sense.  The only other thing that makes a bit more sense is a campaign of a hacker who has an axe to grind with religion but really, if that were the case (not suggesting or condoning this) why wouldn't they hit some high profile target like Joel Osteen or The 700 Club.  So really, the only thing that makes much sense is a rival coin, which is sad to think about, or someone that doesn't realize no pool all that hash goes solo (and for the short term, that's a zero sum game, maybe long range the lack of a pool drives out other miners, but that's a bit hard to fathom).

We need more pool servers, I've offered as well to buy and run one if the price wasn't outlandish but I think the Dev wants to get a more finished product out there before that sort of thing happens.  The counter argument to that is if there were one or two or three other supporters (I won't name anyone at the risk of offending, but I'd wager there's five or six posters in this thread contributing half the posts), like myself, that were willing to buy or at least Co-Lo a pool server under the direction of the Dev with the understanding it would be remotely accessed and upgraded on the short term by him and after his pool software was "prime time", would then become the hosts duty, there would be enough takers.
member
Activity: 70
Merit: 10
I agree there is a problem.  On the bright side, the code itself on the client side still looks solid and on the pool side, OK.

Im going for the low hanging fruit first.  The network rack is plugged into a 100mbps service, and the first thing that didnt smell very good is the entire bandwidth is utilized.  My voip phone is down, everything down.  

So I installed an anti-ddos firewall program on the web server and sure enough we are being ddossed.  I see about 50 IPs that keep sending some binary data about 60 times per second.

Otoh, the pool traffic is pretty clear, its XML back and forth.

So I just started adding rules and blocking the binary traffic.  
Also, there are quite a few servers out there that have not upgraded that are hogging some of the bandwidth, so I had to ban some of those IPs also.  Now we are down to about 17% utilization, try it again please.

Ill look at the 'health down' messages on my box now also.

Was afraid that might happen. Seems to happen a lot these days, DDoS the pools to knock miners off the network so you can find more blocks.

Does getting pool down errors still massively slow down miner performance? If miners smoothly revert to solo mining when the pool goes down with no significant drop in performance then the hit to the network hashrate would be low and there would be no motivation to DDoS (not that that'd necessarily stop them).
full member
Activity: 1176
Merit: 215
Jesus is the King of Kings and Lord of Lords
Anyway, your clients will solo mine when you lose the pool connection, so its not really a problem.
The hashrate in the pool is also lower than expected. But maybe that's because they are jumping on and off.
The "poolmining" tag also sometimes switches to 'false'.

There is a problem with this and I'm talking about the main net. Mining constantly switches between pool and solo (true/false) and it definitely affects performance. Even in the short periods of time when "poolmining" says "true", there's always the "POOL DOWN-REVERTING TO SOLO MINING" error in the "poolinfo3". With the constant switching we are not mining the same as without switching (e.g. number of shares submitted), because I see that CPU usage is all over the place, at times even dropping to less than 10% instead of the constant 99%. The hash rate also plummets during the constant jumping from solo to pool and vice versa. This probably also affects solo mining because I'm not sure how effective is to solo mine for only a few seconds and then get interrupted again.

Also, when I stopped mining on one of the computers and then resumed, it could never go back to its previously established hash rate, but only around 60% of it, while other identical machines are still on the same hash rate, as though there's some kind of an age priority. If it's of any significance, on the restarted machine, "miningpulse" parameter is around 6000, while on the uninterrupted ones it's about 500K.

Isn't all this just a simple issue with the lack of CPU power on the server? I mean, it could be easily solved by employing a more powerful server and I bet that a few people here would be willing to donate for the costs, myself included. Or simply open source the pool and somebody will host it on a higher-end machine.


I agree there is a problem.  On the bright side, the code itself on the client side still looks solid and on the pool side, OK.

Im going for the low hanging fruit first.  The network rack is plugged into a 100mbps service, and the first thing that didnt smell very good is the entire bandwidth is utilized.  My voip phone is down, everything down.  

So I installed an anti-ddos firewall program on the web server and sure enough we are being ddossed.  I see about 50 IPs that keep sending some binary data about 60 times per second.

Otoh, the pool traffic is pretty clear, its XML back and forth.

So I just started adding rules and blocking the binary traffic.  
Also, there are quite a few servers out there that have not upgraded that are hogging some of the bandwidth, so I had to ban some of those IPs also.  Now we are down to about 17% utilization, try it again please.

Ill look at the 'health down' messages on my box now also.

full member
Activity: 221
Merit: 100
The hashrate is half as before and at pollinfo3 it says that is down and returning to minningpolo.

Does need to upgrade the wallet to the latest version of 1.0.2.5? How i do the upgrade in windows?

On 1.0.2.5 something is different, this is what I see in that line:

Code:
"poolinfo3": "CFW 08-30-2017 20:39:16; Checking on Pool Health to see if back up...08-30-2017 20:40:21; ",

But CPU usage is still chaotic and not nearly fully utilized.

If you increase the gneproclimit then the cpu usage increase to.. but than is no more minning because as i understood the pool has an 25 limit threads. But for example my 24 cpu's are used just as 50% .


the DEV was warning that hashrate will drop with the updates as he implemented some changes in the algo.  hopefully this wouldn't cut down the output
member
Activity: 83
Merit: 11
The hashrate is half as before and at pollinfo3 it says that is down and returning to minningpolo.

Does need to upgrade the wallet to the latest version of 1.0.2.5? How i do the upgrade in windows?

On 1.0.2.5 something is different, this is what I see in that line:

Code:
"poolinfo3": "CFW 08-30-2017 20:39:16; Checking on Pool Health to see if back up...08-30-2017 20:40:21; ",

But CPU usage is still chaotic and not nearly fully utilized.

If you increase the gneproclimit then the cpu usage increase to.. but than is no more minning because as i understood the pool has an 25 limit threads. But for example my 24 cpu's are used just as 50% .
Pages:
Jump to: