|
User Name Miner Name Hashes Per Sec Hashes Per Sec2 Shares Reported
inblue blu11 834457.71 839418.82 22 9/1/2017 6:44:00 AM
Inblue, what kind of machine is this at the top?
|
|
|
|
|
Its 06:00AM, and the pool is UP and I see we solved a block almost every hour.
If you have a screen shot of the actual error (not one that had to do with upgrading the database), please post it.
As far as hosting on one of the top providers, If you would like to pay $3-4 an hour and host one on Azure, Im sure it would work also, and I can help direct you on setting it up on a dedicated server.
|
|
|
|
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. Yeah, we are live on cloudflare. The reason you dont see the testing browser for 5 seconds when you hit the pool, is the switch for 'we are under attack' is off, but its still filtering attackers. Im afraid to turn it on, as I dont want to disrupt the API calls as weve had enough problems for a few days. Ill expiriment with it in the next two days. According to the report weve had 5.3 million hits since 4pm (4 hours ago). It must be doing something, because my VOIP phone is working again, and I was ironically on the phone talking to a salesperson for an anti-ddos service (lol) earlier.  Anyway, one feature cloudflare gives us is free HTTPS on every subdomain. Thats not working yet for some reason, although it is working on https://www.biblepay.org. Ill check into that asap for pool.biblepay.org. |
|
|
|
Dev is so active that I can't keep up with the new versions, as soon as I installed 1.0.2.6 on 10+ computers, 1.0.2.7 showed up.  Edit: I can't connect on 1.0.2.7, debug.log at the end: 2017-08-31 20:39:27 Loaded 70 addresses from peers.dat 1ms
2017-08-31 20:39:27 dnsseed thread start
2017-08-31 20:39:27 net thread start
2017-08-31 20:39:27 mnbcon thread start
2017-08-31 20:39:27 addcon thread start
2017-08-31 20:39:27 opencon thread start
2017-08-31 20:39:27 msghand thread start
2017-08-31 20:39:27 BibleMiner -- started thread 0.000000
2017-08-31 20:39:27 BibleMiner -- started thread 1.000000
2017-08-31 20:39:27 BibleMiner -- started thread 2.000000
2017-08-31 20:39:28 BibleMiner -- started thread 3.000000
2017-08-31 20:39:28 BibleMiner -- started thread 4.000000
2017-08-31 20:39:28 ** Started 4.000000 BibleMiner threads. ** ^M
2017-08-31 20:39:28 init message: Done loading
2017-08-31 20:39:31 socket recv error Connection reset by peer (104)
2017-08-31 20:39:36 Loading addresses from DNS seeds (could take a while)
2017-08-31 20:39:37 42 addresses found from DNS seeds
2017-08-31 20:39:37 dnsseed thread exit
2017-08-31 20:41:37 socket recv error Connection reset by peer (104)
I just download it for windows 64 and it is still the 1.0.2.6 I just verified the 64 bit download on www.biblepay.org: It is 1.0.2.7. To upgrade on windows: Just download and run the installer- it upgrades the registry entries automatically. |
|
|
|
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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
|
BiblePay Non-Mandatory Upgrade Available
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
Pool Miners: Please upgrade to alleviate load on the pool.
|
|
|
|
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. |
|
|
|
|
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.
|
|
|
|
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. |
|
|
|
Thanks for your efforts on the pool  I have seen you mentioned block 7000 twice. Maybe I over look the discussion, and I also did not find any clue from OP, may I know what will happen on block 7000? As far as block 7000, Ive been working with a couple members on their ideas of us 'raising the bar' and current 'risks'. The primary risk being mitigated in f7000 is preventing the ability to farm out x11 hashes to GPUs. The other feature in f7000, raising the bar, is requiring the bible hash to emit either a txid, biblepay address, or blockhash at the end of the biblehash chained verses. We believe this raises the bar so high, no one would make an attempt to copy the bible, the logic, and the full node core into an ASIC or GPU, and in addition, requires the full node to arrive at the solution. This means that at block 7000, the only people that should be able to mine this coin are full nodes who must be online to arrive at each block solution. The hashing itself will be slower, because each hash will actually be composed of two biblehashes plus the tx lookup. More can be found here in the testing thread: https://bitcointalk.org/index.php?topic=2070177.40So, that's mean there is no way to mine biblepay with miner like cpuminer (I was actually waiting for someone to add PoB algorithm into cpuminer) in future. Full node is required in order to mine this coin, like what we do it currently by using biblepay wallet to mine. Am I right? Correct- If someone were to make it work with cpuminer, it would go against what the vision is- because then you could have a botnet of blackboxes, generating heat, and not doing anything useful. The vision is to only allow the useful nodes to partake in the subsidies. |
|
|
|
|
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.
|
|
|
|
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. |
|
|
|
Thanks for your efforts on the pool I have seen you mentioned block 7000 twice. Maybe I over look the discussion, and I also did not find any clue from OP, may I know what will happen on block 7000? As far as block 7000, Ive been working with a couple members on their ideas of us 'raising the bar' and current 'risks'. The primary risk being mitigated in f7000 is preventing the ability to farm out x11 hashes to GPUs. The other feature in f7000, raising the bar, is requiring the bible hash to emit either a txid, biblepay address, or blockhash at the end of the biblehash chained verses. We believe this raises the bar so high, no one would make an attempt to copy the bible, the logic, and the full node core into an ASIC or GPU, and in addition, requires the full node to arrive at the solution. This means that at block 7000, the only people that should be able to mine this coin are full nodes who must be online to arrive at each block solution. The hashing itself will be slower, because each hash will actually be composed of two biblehashes plus the tx lookup. More can be found here in the testing thread: https://bitcointalk.org/index.php?topic=2070177.40 |
|
|
|
I think oliwer21 was referring to the tithe blocks which don't bring rewards? Either way, it's not just you, nobody got anything in the last X hours because of the pool difficulties, otherwise that would not be the case, of course you get paid per share contributed, but the pool didn't find any blocks for a long time. Don't worry, it will be resolved soon, we have a great dev.
Youre rigt. I dont expect ill get reward for block 5455 cuz i wast minning on blocks betwen 5444 and 5455. But i was mining betwen 5388 and 5444 with shares 15-17... But im not even on block distribution list of 5444 block. Oliwer, there are a lot of dynamics here. One, we have over 750 solo miners out there (I base that on yesterdays high of 750 connections to my external node). Only about 200 pool users hit the pool simultaneously (although granted, we have over 1000 connections, since multiple threads connect per worker), but anyway let me move on. The pool is only receiving 20% of the traffic. It is very possible sometimes the pool will only solve a few blocks in a half a day due to random difficulty and luck. On the tithe blocks, to make this system fair for everyone, the difficulty is lowered to a miniscule amount on tithe blocks. So those blocks do fly by without much work from the miners. I think in our case, there are solo miners out there that are looking at the forward value of this coin. We will find out a lot more when we hit block 7000, as they will all be forced to upgrade at the same time and hopefully we will know more about who these miners are. I do have an idea on the performance of the pool but this is getting redicules (IE being attacked already, being such a new pool). I'm thinking we enhance the protocol to handle an unlimited amount of threads per connection, and make the threads wait and speak back to the pool as a single unit. More on that later. That will have to be next as Im already deep into the next feature, but seems like something valuable we can do. I dont care of solo miners. I mine on pool. Pool get coins and all my my work is wasted cuz i wasnt minin i this stupid 20 mins when block was found. That only i think its unfair and stupid? If you dont have the anointing of patience this coin isnt for you. Were not about greed here. |
|
|
|
Hmm, this was discussed before but I can't remember if the pool will only count you if you're on the leaderboard at the time of a block find. Even though that's not so logical, it seems to be your case. But that would allow for pool hopping etc.
You do have to be on the leaderboard to be paid in the block distribution when a block is solved. But, to combat pool hopping there are rounds, and in each round the system decays your HPS2 based on the shares submitted. Thats why if you unplug your cable for a while in the current round, your HPS2 starts diminishing slowly. |
|
|
|
I think oliwer21 was referring to the tithe blocks which don't bring rewards? Either way, it's not just you, nobody got anything in the last X hours because of the pool difficulties, otherwise that would not be the case, of course you get paid per share contributed, but the pool didn't find any blocks for a long time. Don't worry, it will be resolved soon, we have a great dev.
Youre rigt. I dont expect ill get reward for block 5455 cuz i wast minning on blocks betwen 5444 and 5455. But i was mining betwen 5388 and 5444 with shares 15-17... But im not even on block distribution list of 5444 block. Oliwer, there are a lot of dynamics here. One, we have over 750 solo miners out there (I base that on yesterdays high of 750 connections to my external node). Only about 200 pool users hit the pool simultaneously (although granted, we have over 1000 connections, since multiple threads connect per worker), but anyway let me move on. The pool is only receiving 20% of the traffic. It is very possible sometimes the pool will only solve a few blocks in a half a day due to random difficulty and luck. On the tithe blocks, to make this system fair for everyone, the difficulty is lowered to a miniscule amount on tithe blocks. So those blocks do fly by without much work from the miners. I think in our case, there are solo miners out there that are looking at the forward value of this coin. We will find out a lot more when we hit block 7000, as they will all be forced to upgrade at the same time and hopefully we will know more about who these miners are. I do have an idea on the performance of the pool but this is getting redicules (IE being attacked already, being such a new pool). I'm thinking we enhance the protocol to handle an unlimited amount of threads per connection, and make the threads wait and speak back to the pool as a single unit. More on that later. That will have to be next as Im already deep into the next feature, but seems like something valuable we can do. |
|
|
|
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. |
|
|
|
Hmm, Im unable to reproduce this. On my 64bit windows desktop I navigate to: www.biblepay.orgClick download 64 bit windows wallet. Open download folder. Copy file to c:\ Run new file. No installer error; 1.0.2.5 loads over old version. Runs. Please clarify where you are downloading from and how you are saving it. |
|
|
|
|
Show Posts
