However this pool is dead since it never switched from proportional, just a few hoppers and a few dummies; why Jine let it die is odd.
Strangely the pool hasn't been hopped for the last month or so.
Topic: [DOWN] Bitlc.net - P2SH, No invalid blocks, Custom payouts, EU, 0% fee, LP - page 4. (Read 180987 times)
January 11, 2013, 05:15:13 AM
Strangely the pool hasn't been hopped for the last month or so.
January 11, 2013, 05:03:08 AM
He doesn't monitor the forum much, you might check the IRC channel. There was a point when his phone number in Sweden was up, you could call it if there was some problem. However this pool is dead since it never switched from proportional, just a few hoppers and a few dummies; why Jine let it die is odd.
January 11, 2013, 04:47:35 AM
just a poke it see if jine is alive .... so he can fill the wallet .... 
January 06, 2013, 08:16:10 PM
I've emailed support twice now. No replies so far.
Unusual. Jine has pretty good at replying to my emails. Try again using both email addresses.
It's very dodgy (and must be very annoying for you), not having funds in the hot wallet for over a week and not responding to emails about it. It's not good if you're trying to pay bills with your mined coins.
At least Bitlc is a public company with a known pool op, and based on his previous actions I'd expect him to honour his obligations eventually.
Sorry I can't help more.
January 06, 2013, 08:03:19 PM
I've emailed support twice now. No replies so far.
January 06, 2013, 07:29:54 PM
*bump*
Insufficient funds errors for over a week now.
Insufficient funds errors for over a week now.
If you email Jine he should reply quite quickly:
[email protected]
[email protected]
January 06, 2013, 07:22:59 PM
*bump*
Insufficient funds errors for over a week now.
Insufficient funds errors for over a week now.
January 02, 2013, 11:29:38 PM
Any chance we can get the hot wallet topped off a bit ? It's been several days that I have not been able to withdraw BTC from my mining account.
September 19, 2012, 06:29:36 PM
No prob... I'll keep mining as usual... Tks!
September 19, 2012, 06:28:57 PM
Keep mining if you want to be honest and return the coins, or deposit a few coins using the wallet-service.
Or just register a new account, it's totally up to you.
I appreciate your honesty tho.
--
Regards, Jim
Bit LC Inc.
Or just register a new account, it's totally up to you.
I appreciate your honesty tho.
--
Regards, Jim
Bit LC Inc.
September 19, 2012, 06:27:06 PM
Ahh Okay!
You're right, there is two identical deposits into my account: "0.00000000" that I withdraw it to my wallet.
Please, how can I return those coins to you? Just keep mining? =P
Tks,
Thiago
You're right, there is two identical deposits into my account: "0.00000000" that I withdraw it to my wallet.
Please, how can I return those coins to you? Just keep mining? =P
Tks,
Thiago
September 19, 2012, 06:24:23 PM
Hi!
It's prob. because of the "leap-second" bug we encountered a few months back (check our twitter for more info on that), which made deposits to your account be processed more then once. (MySQL hung and became really unstable/unresponsive) If you made a outgoing payment during that bug, it will have set your balance to a negative amount to compensate for the "extra" coins your received due to the "extra" deposits.
There is only THREE accounts with a negative balance, and judging by your nick i can figure out which ones yours - I can reset your balance to zero if you want to.
--
Regards, Jim
Bit LC Inc.
It's prob. because of the "leap-second" bug we encountered a few months back (check our twitter for more info on that), which made deposits to your account be processed more then once. (MySQL hung and became really unstable/unresponsive) If you made a outgoing payment during that bug, it will have set your balance to a negative amount to compensate for the "extra" coins your received due to the "extra" deposits.
There is only THREE accounts with a negative balance, and judging by your nick i can figure out which ones yours - I can reset your balance to zero if you want to.
--
Regards, Jim
Bit LC Inc.
September 19, 2012, 06:15:23 PM
Hi!
Why my balance is negative?
Tks,
Thiago
Why my balance is negative?
Tks,
Thiago
September 16, 2012, 12:58:50 PM
I must have missed a configuration on one of the rigs somewhere. I actually do not like running through TOR since it saps ~2% of my hashrate due to latency and it should be only running on one pool now, but apparently I missed something somewhere.
I'll take it up in email though.
I'll take it up in email though.
September 16, 2012, 11:13:16 AM
I'm only going to address the 4th point, as it's related to the stale/eff ratio.
4. Taken directly from our poolserver a few hours ago, associated with your worker, today:
If you have any more questions or similar on your mind, contact me using IRC or e-mail.
This "issue" is closed and it adds unnecessary posts to the thread.
4. Taken directly from our poolserver a few hours ago, associated with your worker, today:
Quote
jine@jine:~$ cat ipscrub | xargs -L1 host
205.233.163.109.in-addr.arpa domain name pointer gorz.torservers.net.
36.147.48.199.in-addr.arpa domain name pointer tor-exit-router36-readme.formlessnetworking.net.
200.233.163.109.in-addr.arpa domain name pointer wau.torservers.net.
Host 130.211.32.178.in-addr.arpa. not found: 3(NXDOMAIN)
132.13.120.74.in-addr.arpa domain name pointer bouazizi.torservers.net.
60.171.76.69.in-addr.arpa domain name pointer cpe-69-76-171-60.kc.res.rr.com.
150.15.120.74.in-addr.arpa domain name pointer raskin.torservers.net.
Host 243.73.110.208.in-addr.arpa. not found: 3(NXDOMAIN)
20.86.120.79.in-addr.arpa domain name pointer stargrave.org.
1.178.126.94.in-addr.arpa domain name pointer tor-exit01.solidonetworks.com.
45.147.48.199.in-addr.arpa domain name pointer tor-exit-router45-readme.formlessnetworking.net.
224.53.141.62.in-addr.arpa domain name pointer tor1.digineo.de.
78.216.192.173.in-addr.arpa domain name pointer 173.192.216.78-static.reverse.softlayer.com.
102.189.44.96.in-addr.arpa domain name pointer herngaard.torservers.net.
50.245.167.46.in-addr.arpa domain name pointer torsrvc.snydernet.net.
Host 140.211.32.178.in-addr.arpa. not found: 3(NXDOMAIN)
40.147.48.199.in-addr.arpa domain name pointer tor-exit-router40-readme.formlessnetworking.net.
41.147.48.199.in-addr.arpa domain name pointer tor-exit-router41-readme.formlessnetworking.net.
Host 18.82.110.208.in-addr.arpa. not found: 3(NXDOMAIN)
21.226.47.96.in-addr.arpa domain name pointer bolobolo2.torservers.net.
42.244.226.83.in-addr.arpa domain name pointer c-2af4e253.09-8-686c6d10.cust.bredbandsbolaget.se.
133.227.130.37.in-addr.arpa domain name pointer torland1-this.is.a.tor.exit.server.torland.is.
Host 92.32.173.46.in-addr.arpa. not found: 3(NXDOMAIN)
73.226.237.80.in-addr.arpa domain name pointer tor3.anonymizer.ccc.de.
66.164.14.67.in-addr.arpa domain name pointer 67-14-164-66.kcnap.net.
74.226.237.80.in-addr.arpa domain name pointer tor4.anonymizer.ccc.de.
76.226.237.80.in-addr.arpa domain name pointer tor6.anonymizer.ccc.de.
29.191.166.108.in-addr.arpa domain name pointer tor-exit.hexhost.net.
164.181.247.77.in-addr.arpa domain name pointer rainbowwarrior.torservers.net.
165.181.247.77.in-addr.arpa domain name pointer politkovskaja.torservers.net.
Host 146.137.195.69.in-addr.arpa. not found: 3(NXDOMAIN)
205.233.163.109.in-addr.arpa domain name pointer gorz.torservers.net.
36.147.48.199.in-addr.arpa domain name pointer tor-exit-router36-readme.formlessnetworking.net.
200.233.163.109.in-addr.arpa domain name pointer wau.torservers.net.
Host 130.211.32.178.in-addr.arpa. not found: 3(NXDOMAIN)
132.13.120.74.in-addr.arpa domain name pointer bouazizi.torservers.net.
60.171.76.69.in-addr.arpa domain name pointer cpe-69-76-171-60.kc.res.rr.com.
150.15.120.74.in-addr.arpa domain name pointer raskin.torservers.net.
Host 243.73.110.208.in-addr.arpa. not found: 3(NXDOMAIN)
20.86.120.79.in-addr.arpa domain name pointer stargrave.org.
1.178.126.94.in-addr.arpa domain name pointer tor-exit01.solidonetworks.com.
45.147.48.199.in-addr.arpa domain name pointer tor-exit-router45-readme.formlessnetworking.net.
224.53.141.62.in-addr.arpa domain name pointer tor1.digineo.de.
78.216.192.173.in-addr.arpa domain name pointer 173.192.216.78-static.reverse.softlayer.com.
102.189.44.96.in-addr.arpa domain name pointer herngaard.torservers.net.
50.245.167.46.in-addr.arpa domain name pointer torsrvc.snydernet.net.
Host 140.211.32.178.in-addr.arpa. not found: 3(NXDOMAIN)
40.147.48.199.in-addr.arpa domain name pointer tor-exit-router40-readme.formlessnetworking.net.
41.147.48.199.in-addr.arpa domain name pointer tor-exit-router41-readme.formlessnetworking.net.
Host 18.82.110.208.in-addr.arpa. not found: 3(NXDOMAIN)
21.226.47.96.in-addr.arpa domain name pointer bolobolo2.torservers.net.
42.244.226.83.in-addr.arpa domain name pointer c-2af4e253.09-8-686c6d10.cust.bredbandsbolaget.se.
133.227.130.37.in-addr.arpa domain name pointer torland1-this.is.a.tor.exit.server.torland.is.
Host 92.32.173.46.in-addr.arpa. not found: 3(NXDOMAIN)
73.226.237.80.in-addr.arpa domain name pointer tor3.anonymizer.ccc.de.
66.164.14.67.in-addr.arpa domain name pointer 67-14-164-66.kcnap.net.
74.226.237.80.in-addr.arpa domain name pointer tor4.anonymizer.ccc.de.
76.226.237.80.in-addr.arpa domain name pointer tor6.anonymizer.ccc.de.
29.191.166.108.in-addr.arpa domain name pointer tor-exit.hexhost.net.
164.181.247.77.in-addr.arpa domain name pointer rainbowwarrior.torservers.net.
165.181.247.77.in-addr.arpa domain name pointer politkovskaja.torservers.net.
Host 146.137.195.69.in-addr.arpa. not found: 3(NXDOMAIN)
If you have any more questions or similar on your mind, contact me using IRC or e-mail.
This "issue" is closed and it adds unnecessary posts to the thread.
September 16, 2012, 11:09:19 AM
1. Yes, I can provide pictures if you disbelieve me.
2. If there are stales or other efficiency problems, it's not on my end, since most of the pools have little problem and I consistently return 1000% effecency. If it dips down to 400%, I investigate as to what the problem is. Are you not supporting rollNtime? Perhaps that's the problem? If your pool can't keep up with giving me work and you don't support rollNtime, then that might be part of the issue. You should enable rollNtime for fast miners.
3. You're right, it's not a small operation, but it's a legitimate one, not a botnet or proxy pool. Additionally, as I said, in a month an a half you'll have a single machine with 2x the hashrate I'm hitting you with now; that's going to be a real problem.
4. The only reason I was hitting you with TOR (and it shouldn't have been hitting you with TOR this week) was because, up until now, it was not possible to send connections through different proxies for different pools. After working with Kano last week to get that ability added to cgminer, I turned off TOR for your (and every other pool except one). So you should not have seen TOR connections in the past week or so.
5. It's been more than a year though, you could not have found time in a year, really?
As to why I'm not mining on my own pool, there's a variety of reasons, but primarily because my pool is not hoppable, simple as that. But I do mine on it as a backup when I'm not mining anywhere else.
2. If there are stales or other efficiency problems, it's not on my end, since most of the pools have little problem and I consistently return 1000% effecency. If it dips down to 400%, I investigate as to what the problem is. Are you not supporting rollNtime? Perhaps that's the problem? If your pool can't keep up with giving me work and you don't support rollNtime, then that might be part of the issue. You should enable rollNtime for fast miners.
3. You're right, it's not a small operation, but it's a legitimate one, not a botnet or proxy pool. Additionally, as I said, in a month an a half you'll have a single machine with 2x the hashrate I'm hitting you with now; that's going to be a real problem.
4. The only reason I was hitting you with TOR (and it shouldn't have been hitting you with TOR this week) was because, up until now, it was not possible to send connections through different proxies for different pools. After working with Kano last week to get that ability added to cgminer, I turned off TOR for your (and every other pool except one). So you should not have seen TOR connections in the past week or so.
5. It's been more than a year though, you could not have found time in a year, really?
As to why I'm not mining on my own pool, there's a variety of reasons, but primarily because my pool is not hoppable, simple as that. But I do mine on it as a backup when I'm not mining anywhere else.
September 16, 2012, 10:37:45 AM
One question tho, why aren't you mining at your own pool, with your FPGAs?
EDIT: Funny, i just an e-mail AND a PM with people asking the same question. Things doesn't add upp here...
EDIT: Funny, i just an e-mail AND a PM with people asking the same question. Things doesn't add upp here...
September 16, 2012, 10:28:09 AM
So you're claiming that you're mining with a FPGA cluster of far over 600gh? Jikes, that's impressive! Kudos for that!
2. The botnet detection is based upon the effeciency (getworks vs. stales in this case), amount of connections, source of connections, amount of unique IP's, IP2location for those IP's and much more I'm not going to publicly announce, as it in fact are there for a reason.
3. Yes, but stales do consume and waste bandwidth - the point i was trying to make was that it was no "small" operation, it was a massive spike in hashrate, connections, traffic, getworks and stales.
4. I really doubt that, especially as you're using TOR (might i ask why?) for the miners (which is one of the things our botnet detection adds points for).
5. We're working on that, see my posts above. I'm well aware of that. We've haven't just had the time (and money, as time is money) to implement it...
--
Regards, Jim
Bit LC Inc.
https://www.bitlc.net
EDIT:
2. The botnet detection is based upon the effeciency (getworks vs. stales in this case), amount of connections, source of connections, amount of unique IP's, IP2location for those IP's and much more I'm not going to publicly announce, as it in fact are there for a reason.
3. Yes, but stales do consume and waste bandwidth - the point i was trying to make was that it was no "small" operation, it was a massive spike in hashrate, connections, traffic, getworks and stales.
4. I really doubt that, especially as you're using TOR (might i ask why?) for the miners (which is one of the things our botnet detection adds points for).
5. We're working on that, see my posts above. I'm well aware of that. We've haven't just had the time (and money, as time is money) to implement it...
--
Regards, Jim
Bit LC Inc.
https://www.bitlc.net
EDIT:
Quote
I am also very disappointed that you have basically told me you are going to steal the funds that I have already accumulated for work performed simply because your pool can't handle my hashrate.
I've sent you an e-mail regarding that, we can take that privately. September 16, 2012, 10:17:51 AM
As I informed you in the email, your botnet detection algorithm needs some work. My hashrate is neither a proxy pool nor a botnet, it is raw hashing power backed by FPGA units. There's two problems with your decision:
1. You are banning based on erroneous data. If you don't want the hashrate, that's fine, but do not claim that it's a botnet or a proxy pool, because you have no proof of this and I can, in fact, prove otherwise. Would you like photos of what that type of hashrate looks like?
2. The amount of getworks is not the fault of the hashrate, it's a flaw in the protocol which you would run into this problem regardless of whether or not I was providing you with the hashrate or someone else was. The amount of getworks is static with the hashrate. Since my effeciency is upwards of 1000%, it's better that I provide that hashrate than someone else, who likely has far less effeciency. You are actually doing your pool a disservice by banning based on getwork, you should ban based on efficiency.
3. Bandwidth - again, completely immaterial, since that hashrate would consume that bandwidth, regardless of the source.
4. Your 'lowered efficiency' is not due to my connections, as I said, my efficiency is consistently over 1000% (yes, one thousand percent). If you have low effeciency, you need to look elsewhere. If your connection problems are there, it's because you can't handle the hashrate, not because my particular brand of hashrate is causing you problems. Again, you would run into the same problem regardless of the source.
5. If you do not want pool hoppers, why are you running a proportional pool in this day and age? There can't be any reasonable explanation for running a proportional pool other than you don't mind pool hoppers.
I am also very disappointed that you have basically told me you are going to steal the funds that I have already accumulated for work performed simply because your pool can't handle my hashrate. I am very curious as to what you're going to do to the people with a single Minirig SC, since your pool can't even handle a fraction of the hashrate of a single unit. Are you going to ban them and steal their funds, as well?
1. You are banning based on erroneous data. If you don't want the hashrate, that's fine, but do not claim that it's a botnet or a proxy pool, because you have no proof of this and I can, in fact, prove otherwise. Would you like photos of what that type of hashrate looks like?
2. The amount of getworks is not the fault of the hashrate, it's a flaw in the protocol which you would run into this problem regardless of whether or not I was providing you with the hashrate or someone else was. The amount of getworks is static with the hashrate. Since my effeciency is upwards of 1000%, it's better that I provide that hashrate than someone else, who likely has far less effeciency. You are actually doing your pool a disservice by banning based on getwork, you should ban based on efficiency.
3. Bandwidth - again, completely immaterial, since that hashrate would consume that bandwidth, regardless of the source.
4. Your 'lowered efficiency' is not due to my connections, as I said, my efficiency is consistently over 1000% (yes, one thousand percent). If you have low effeciency, you need to look elsewhere. If your connection problems are there, it's because you can't handle the hashrate, not because my particular brand of hashrate is causing you problems. Again, you would run into the same problem regardless of the source.
5. If you do not want pool hoppers, why are you running a proportional pool in this day and age? There can't be any reasonable explanation for running a proportional pool other than you don't mind pool hoppers.
I am also very disappointed that you have basically told me you are going to steal the funds that I have already accumulated for work performed simply because your pool can't handle my hashrate. I am very curious as to what you're going to do to the people with a single Minirig SC, since your pool can't even handle a fraction of the hashrate of a single unit. Are you going to ban them and steal their funds, as well?
September 16, 2012, 09:14:44 AM
A short update from us.
We have decided to ban a user that previously has caused us trouble mining via larger botnets and/or a proxy-pool. I let him back in and even compensated him for the inconvenience back then.
He's was now using ~25-30 connections via TOR to hide his activity this time, we've been in contact with him and informed him about the situation. The amount of getworks was totally of the charts to, our environment can't handle spikes from a few hundred getworks/s to multiple thousands over a short period of time. Directly comparable with the "slashdot-effect".
Bandwidth wise it's a jump from about 1MB/s to 8-9MB/s during the hops - it's a pretty massive change.
He's the one responsible for the HUGE increase in hash rate right after new rounds (~800gh hopper, my guess it's some of the pool-hopping-proxys, maybe not ABCPool this time tho).
He's also the one responsible for the lowered efficiency during those rounds and connections troubles we've gotten reports for over the past days.
The payment issues (Insufficient funds error) should be resolved now, permanently. We've taken some actions to make it possible for us to access the cold-stored funds easier without making it a security risk.
Better safe then sorry!
PPLNS is still a top priority, to solve the "hopper problem" permanently.
I cannot express in words how I'm sorry I am for all the delays for that.
We've going to focus on that for the entire next week, you have my word on that.
If you have any questions, don't hesitate to contact us!
--
Regards, Jim
Bit LC Inc.
https://www.bitlc.net/
We have decided to ban a user that previously has caused us trouble mining via larger botnets and/or a proxy-pool. I let him back in and even compensated him for the inconvenience back then.
He's was now using ~25-30 connections via TOR to hide his activity this time, we've been in contact with him and informed him about the situation. The amount of getworks was totally of the charts to, our environment can't handle spikes from a few hundred getworks/s to multiple thousands over a short period of time. Directly comparable with the "slashdot-effect".
Bandwidth wise it's a jump from about 1MB/s to 8-9MB/s during the hops - it's a pretty massive change.
He's the one responsible for the HUGE increase in hash rate right after new rounds (~800gh hopper, my guess it's some of the pool-hopping-proxys, maybe not ABCPool this time tho).
He's also the one responsible for the lowered efficiency during those rounds and connections troubles we've gotten reports for over the past days.
The payment issues (Insufficient funds error) should be resolved now, permanently. We've taken some actions to make it possible for us to access the cold-stored funds easier without making it a security risk.
Better safe then sorry!
PPLNS is still a top priority, to solve the "hopper problem" permanently.
I cannot express in words how I'm sorry I am for all the delays for that.
We've going to focus on that for the entire next week, you have my word on that.
If you have any questions, don't hesitate to contact us!
--
Regards, Jim
Bit LC Inc.
https://www.bitlc.net/
Jump to: