BiblePay - TestNet Thread - Pool Testing for Proof of Bible Hash Pool (PoBh)

[inblue]

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.

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.

[bible_pay]

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.

[inblue]

Great news! Every one of those three improvements should boost performance by a few times, and then when you multiply all three...

[tiras]

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

[bible_pay]

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.

[bible_pay]

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.

[tiras]

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
}

[bible_pay]

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.

[616westwarmoth]

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.

[616westwarmoth]

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.

[tiras]

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

[616westwarmoth]

1.0.2.6 is misbehaving a bit.  It closed a few times on the laptop I use, but it's been stable for a bit (although it's been having trouble with connecting to the pool).

The desktop (running at genproc 12) exited while I was away.

The last lines of the debug look like this:

2017-08-31 17:35:39 Loading addresses from DNS seeds (could take a while)
2017-08-31 17:35:39 39 addresses found from DNS seeds
2017-08-31 17:35:39 dnsseed thread exit
2017-08-31 17:36:32 socket recv error An existing connection was forcibly closed by the remote host.  (10054)
2017-08-31 17:37:02 CMasternodeSync::IsBlockchainSynced -- found enough peers on the same height as we are, done
2017-08-31 17:37:19 socket recv error An existing connection was forcibly closed by the remote host.  (10054)
2017-08-31 17:37:37 socket recv error An existing connection was forcibly closed by the remote host.  (10054)
2017-08-31 17:41:41 socket recv error An existing connection was forcibly closed by the remote host.  (10054)

[bible_pay]

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

Yeah, this pool wont run on a php or mysql host, it requires SQL 2012, .NET 4.5, biblepayd running as an instance on a static IP, etc.  It could possibly be hosted on a windows hosting service, I suppose we'll find out when our first volunteer tries, but on my end I already paid for cloudflare and we should know within 24 hours if it helps.

[bible_pay]

1.0.2.6 is misbehaving a bit.  It closed a few times on the laptop I use, but it's been stable for a bit (although it's been having trouble with connecting to the pool).

The desktop (running at genproc 12) exited while I was away.

The last lines of the debug look like this:

2017-08-31 17:35:39 Loading addresses from DNS seeds (could take a while)
2017-08-31 17:35:39 39 addresses found from DNS seeds
2017-08-31 17:35:39 dnsseed thread exit
2017-08-31 17:36:32 socket recv error An existing connection was forcibly closed by the remote host.  (10054)
2017-08-31 17:37:02 CMasternodeSync::IsBlockchainSynced -- found enough peers on the same height as we are, done
2017-08-31 17:37:19 socket recv error An existing connection was forcibly closed by the remote host.  (10054)
2017-08-31 17:37:37 socket recv error An existing connection was forcibly closed by the remote host.  (10054)
2017-08-31 17:41:41 socket recv error An existing connection was forcibly closed by the remote host.  (10054)

Oh great, right after I released it to the main thread.  I have a feeling this is related to the shared mining comm volatile bool I added.
Alright I made a change and checked it in and Im burning it in now, and compiling a win version.  Ill post here in about 4 hours when windows 1027 is ready.  Cant guarantee this is the exact problem but its worth a shot.

[tiras]

1.0.2.6 is misbehaving a bit.  It closed a few times on the laptop I use, but it's been stable for a bit (although it's been having trouble with connecting to the pool).

The desktop (running at genproc 12) exited while I was away.

The last lines of the debug look like this:

2017-08-31 17:35:39 Loading addresses from DNS seeds (could take a while)
2017-08-31 17:35:39 39 addresses found from DNS seeds
2017-08-31 17:35:39 dnsseed thread exit
2017-08-31 17:36:32 socket recv error An existing connection was forcibly closed by the remote host.  (10054)
2017-08-31 17:37:02 CMasternodeSync::IsBlockchainSynced -- found enough peers on the same height as we are, done
2017-08-31 17:37:19 socket recv error An existing connection was forcibly closed by the remote host.  (10054)
2017-08-31 17:37:37 socket recv error An existing connection was forcibly closed by the remote host.  (10054)
2017-08-31 17:41:41 socket recv error An existing connection was forcibly closed by the remote host.  (10054)

Oh great, right after I released it to the main thread.  I have a feeling this is related to the shared mining comm volatile bool I added.
Alright I made a change and checked it in and Im burning it in now, and compiling a win version.  Ill post here in about 4 hours when windows 1027 is ready.  Cant guarantee this is the exact problem but its worth a shot.

started 1.0.2.6 on 3 win and 2 linux boxes.  all are running stable against the pool

[616westwarmoth]

It may have been a fluke, it's run stable the last couple hours on both the laptop that originally struggled and the desktop. 

[tiras]

1.0.2.6 is misbehaving a bit.  It closed a few times on the laptop I use, but it's been stable for a bit (although it's been having trouble with connecting to the pool).

The desktop (running at genproc 12) exited while I was away.

The last lines of the debug look like this:

2017-08-31 17:35:39 Loading addresses from DNS seeds (could take a while)
2017-08-31 17:35:39 39 addresses found from DNS seeds
2017-08-31 17:35:39 dnsseed thread exit
2017-08-31 17:36:32 socket recv error An existing connection was forcibly closed by the remote host.  (10054)
2017-08-31 17:37:02 CMasternodeSync::IsBlockchainSynced -- found enough peers on the same height as we are, done
2017-08-31 17:37:19 socket recv error An existing connection was forcibly closed by the remote host.  (10054)
2017-08-31 17:37:37 socket recv error An existing connection was forcibly closed by the remote host.  (10054)
2017-08-31 17:41:41 socket recv error An existing connection was forcibly closed by the remote host.  (10054)

Oh great, right after I released it to the main thread.  I have a feeling this is related to the shared mining comm volatile bool I added.
Alright I made a change and checked it in and Im burning it in now, and compiling a win version.  Ill post here in about 4 hours when windows 1027 is ready.  Cant guarantee this is the exact problem but its worth a shot.

started 1.0.2.6 on 3 win and 2 linux boxes.  all are running stable against the pool

crushed on i7 7700  which I probably pushed too hard with 24 threads :

Code:

2017-08-31 19:06:32 Biblepay Core version 1.0.2.6 (2017-08-31 08:16:50 -0500)
2017-08-31 19:06:32 InitParameterInteraction: parameter interaction: -whitelistforcerelay=1 -> setting -whitelistrelay=1
2>>>
>>>
>>>
2017-08-31 19:06:48 dnsseed thread exit
2017-08-31 19:07:04 

BiblepayMiner -- terminated
2017-08-31 19:07:04 

BiblepayMiner -- terminated
2017-08-31 19:07:04 

BiblepayMiner -- terminated
2017-08-31 19:07:04 

BiblepayMiner -- terminated
2017-08-31 19:07:04 

BiblepayMiner -- terminated
2017-08-31 19:07:04 

BiblepayMiner -- terminated
2017-08-31 19:07:04 

BiblepayMiner -- terminated
2017-08-31 19:07:04 

BiblepayMiner -- terminated
2017-08-31 19:07:04 

BiblepayMiner -- terminated
2017-08-31 19:07:04 

BiblepayMiner -- terminated
2017-08-31 19:07:04 BibleMiner -- started thread 0.000000 
2017-08-31 19:07:04 BibleMiner -- started thread 1.000000 
2017-08-31 19:07:04 BibleMiner -- started thread 2.000000 
2017-08-31 19:07:04 

BiblepayMiner -- terminated
2017-08-31 19:07:04 BibleMiner -- started thread 3.000000 
2017-08-31 19:07:04 

BiblepayMiner -- terminated
2017-08-31 19:07:04 BibleMiner -- started thread 4.000000 
2017-08-31 19:07:04 

BiblepayMiner -- terminated
2017-08-31 19:07:04 

BiblepayMiner -- terminated
2017-08-31 19:07:04 

BiblepayMiner -- terminated
2017-08-31 19:07:04 

BiblepayMiner -- terminated
2017-08-31 19:07:04 BibleMiner -- started thread 5.000000 
2017-08-31 19:07:04 BibleMiner -- started thread 6.000000 
2017-08-31 19:07:04 BibleMiner -- started thread 7.000000 
2017-08-31 19:07:04 BibleMiner -- started thread 8.000000 
2017-08-31 19:07:04 BibleMiner -- started thread 9.000000 
2017-08-31 19:07:05 BibleMiner -- started thread 10.000000 
2017-08-31 19:07:05 BibleMiner -- started thread 11.000000 
2017-08-31 19:07:05 BibleMiner -- started thread 12.000000 
2017-08-31 19:07:05 BibleMiner -- started thread 13.000000 
2017-08-31 19:07:05 BibleMiner -- started thread 14.000000 
2017-08-31 19:07:05 BibleMiner -- started thread 15.000000 
2017-08-31 19:07:05 BibleMiner -- started thread 16.000000 
2017-08-31 19:07:05 BibleMiner -- started thread 17.000000 
2017-08-31 19:07:05 BibleMiner -- started thread 18.000000 
2017-08-31 19:07:05 BibleMiner -- started thread 19.000000 
2017-08-31 19:07:06 BibleMiner -- started thread 20.000000 
2017-08-31 19:07:06 BibleMiner -- started thread 21.000000 
2017-08-31 19:07:06 BibleMiner -- started thread 22.000000 
2017-08-31 19:07:06 BibleMiner -- started thread 23.000000 
2017-08-31 19:07:06  ** Started 24.000000 BibleMiner threads. ** 

2017-08-31 19:07:23 CMasternodeSync::IsBlockchainSynced -- found enough peers on the same height as we are, done
2017-08-31 19:08:36 socket recv error An existing connection was forcibly closed by the remote host.  (10054)
2017-08-31 19:08:53 socket recv error An existing connection was forcibly closed by the remote host.  (10054)
2017-08-31 19:09:10 socket recv error An existing connection was forcibly closed by the remote host.  (10054)
2017-08-31 19:11:07 socket recv error An existing connection was forcibly closed by the remote host.  (10054)
2017-08-31 19:11:18 socket recv error An existing connection was forcibly closed by the remote host.  (10054)
2017-08-31 20:17:04 socket sending timeout: 3625s
2017-08-31 20:17:04 socket sending timeout: 3719s
2017-08-31 20:17:04 socket sending timeout: 3717s
2017-08-31 20:17:04 socket sending timeout: 3717s
2017-08-31 20:17:04 socket sending timeout: 3705s
2017-08-31 20:17:04 socket sending timeout: 3668s
2017-08-31 20:17:04 socket sending timeout: 3745s
2017-08-31 20:17:04 socket sending timeout: 3728s
2017-08-31 20:17:04 socket sending timeout: 3742s
2017-08-31 20:17:05 socket send error An operation was attempted on something that is not a socket.  (10038)

[jaapgvk]

Updated my poolminers to 1.0.2.6. Went without hiccups. I've been mining for a few hours now and everything looks stable.

[bible_pay]

It may have been a fluke, it's run stable the last couple hours on both the laptop that originally struggled and the desktop. 

I dont know, I had the same problem when the pool went down earlier.  It hasnt gone down since then, (I believe because of cloudflare), but anyway, when the pool goes down, the client is reading a new volatile variable that I put in this morning, which may not be threadsafe, so I released 1.0.2.7 using a different method.

If you want to upgrade to 1.0.2.7, its out there now.  You could probably simulate an outage by pulling the cable or disabling the network device and see what the client does - ensure it doesnt crash when getmininginfo says "POOL DOWN".  Could you please try testing that, that would help?

Thanks.

[seasonw]

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

Yeah, this pool wont run on a php or mysql host, it requires SQL 2012, .NET 4.5, biblepayd running as an instance on a static IP, etc.  It could possibly be hosted on a windows hosting service, I suppose we'll find out when our first volunteer tries, but on my end I already paid for cloudflare and we should know within 24 hours if it helps.

It is good to use cloudflare to handle DDOS activities. And I noticed the pool react pretty fast now, wondering if it is already cloudflare protected?

BTW, did you add setting on your pool server to allow connection from cloudflare IP only, because your pool's IP has been exposed previously to DDOS attacker, which they might perform attack directly to your pool's IP without going through the cloudflare. Just my two cents, hope it helps to eliminate your headache on DDOS again.