 Show Posts
|
|
Pages: [1]
|
Use socat.
for mining through tor,
socat tcp-listen:18332,fork,reuseaddr socks4a:127.0.0.1:pool.com:8332,socksport=9050
But that would still leak DNS requests, wouldn't it? That has always been the issue with tools like socat or tsocks. Your miner connects to 127.0.0.1 - no dns there if you use the socks4a option on socat, it does the dns lookup for the pool through the proxy. Hey, that's nifty! Thanks for the tip! As I understand, this helps for situation where miner don't support ntime rolling and pool does, right? What miners don't support ntime rolling yet? I lived in the opinion that ntime rolling is widely supported everywhere. Then I found that some big pools still don't support such simple and important extension, like Deepbit or even 50BTC. But as I understand, this proxy don't help in such situation - pool have to support ntime rolling itself. Maybe the best thing is just to switch to miner and pool which supports ntime rolling, or even give a try to Stratum which implements mining protocol in quite innovative way (yes, this is kind of advertisement for my pool and BtcGuild  . The way I understand it, a miner can only do rolling within itself. If you have several miners on different machines, this proxy will help a lot. But please correct me if this is nonsense! Besides, even without this feature, mining proxies are great tools to have if you use many machines. It makes monitoring, maintenance, setup of new machines or changing the pool and propagating that change to all clients so much easier. I especially like Rollproxy because it's so small and efficient. I've used another proxy before, but it required apache, php, mysql, regular database cleanups, and while it worked well, it was a bit cumbersome to use. |
|
|
|
Unfortunately that doesn't help. What is needed is a way for RollProxy to connect to the Internet through a SOCKS4/5 proxy, not a way for the miners to connect to RollProxy through an additional local proxy.
Use socat. for mining through tor, socat tcp-listen:18332,fork,reuseaddr socks4a:127.0.0.1:pool.com:8332,socksport=9050 But that would still leak DNS requests, wouldn't it? That has always been the issue with tools like socat or tsocks. |
|
|
|
In any case, it seems my debian squeeze server is stuck on python 2.6.6 anyway, which neither offers urllib3 packages, nor satisfies rollproxy's version requirement. Oh well.
Rollproxy on squeeze works fine for me: apt-get install python-pip
pip install argparse
pip install urllib3
python /usr/local/bin/rollproxy.py -v <your pool(s)>
[2012-08-29 08:58:05] Serving HTTP on port 8345
oooh, interesting. and here i tried installing the wheezy packages for urllib3  thank you very much, it is working now. and thank you, too, pooler. rollproxy is great! |
|
|
|
say, pooler, would it be possible to add support for socks proxies in addition to http? this could quite possibly be the best thing since cgminer, if only it had socks support I realize that SOCKS support would be a very nice feature to have. The problem is that the master branch of urllib3 doesn't support SOCKS proxies yet, although developers have been working on it for some time now (see this pull request). One option would be to rewrite RollProxy to use PycURL instead of urllib3, but the problem is that urllib3 seems to be the only decent HTTP library that supports connection pooling. Another option would be to use SocksiPy, which however is buggy, old, and unmaintained. For the above reasons, it's probably better to wait till the urllib3 guys finish implementing SOCKS support. oh. Yeah, you're right. No point in rewriting the thing for another lib. In any case, it seems my debian squeeze server is stuck on python 2.6.6 anyway, which neither offers urllib3 packages, nor satisfies rollproxy's version requirement. Oh well. |
|
|
|
say, pooler, would it be possible to add support for socks proxies in addition to http? this could quite possibly be the best thing since cgminer, if only it had socks support |
|
|
|
My payment is a lot lower on short rounds. It seems that the short ones have a lot more shares/min incoming. PPS means you are paid a set amount per share. If a round is short, you submit less shares. Why would you expect anything else? If you think you are getting paid more or less per share in some scenario, then you have an issue, otherwise, that should clear up your confusion. Oh. I missed the PPS part. It's been a while since I last mined here, and it wasn't PPS back then. Sorry about that. The fact that it still has the setup ('my rewards' page, focus on found blocks, etc.) from the old days didn't help my confusion  Thank for clearing this up. |
|
|
|
|
My payment is a lot lower on short rounds. It seems that the short ones have a lot more shares/min incoming. The recent 1m37s one has almost 50k. Mtred doesn't have THAT many hoppers, does it?
|
|
|
|
You don't earn credit, it is pure PPS. You are paid after every block solve. I can switch that up to a time instead of block solve as well, I just haven't had anyone express a preference. You are paid as much or as little as you earned, since I send out payments as a sendmany, it's only one fee to send to everyone, so I can send out very small fractions of a BTC. Thanks. I like the way this works. |
|
|
|
All you need to do is put either your Dwolla ID or your BTC wallet address as the username. Password can be anything.
I understand that. But what are the conditions for payout? Eligius sends them when the credit reaches ~0.67 BTC, or after one week of inactivity. What happens when I stop mining while still having credit? Are there any statistics for this mode of mining? |
|
|
|
|
I'm interested in mining account-less (username=payment address), but I can't seem to find much information about it. How is it handled? Are there stats? When are miners paid? What happens if I stop mining?
|
|
|
|
|
Unless your utilization (U:) drops, I wouldn't worry.
|
|
|
|
|
A CPU basically loads instructions and data, then applies these instructions to the data. It can do almost any kind of computations. A GPU is a simplified CPU, but thousands of them (not quite accurate, but it works).
What an FPGA does is load only the data. The instructions are already burned in. This allows them to work on the data much, much faster and with less power consumption, but they can only do what they were programmed to, unlike the CPU which can load any kind of instructions. Yes, FPGAs can be re-burned, but that is a far cry from the versatility of CPUs still.
|
|
|
|
|
Paranoia is not an illness, especially not when shady people are involved.
|
|
|
|
|
Hello.
I've been mining since mid-2011 with over a kilowatt worth of cards, have used various software and tools, have been visiting these forums from time to time and I think I can say that I'm definitely no newbie. Please unlock me, as it makes no sense for me to make useless posts in this section.
Thanks
|
|
|
|
Hey. I'm not a newbie. I just haven't bothered to register here before now |
|
|
|
|
