So then I start to wonder, how much memory does pushpoold use when under good load from litecoin miners? I ask because I'm running my instance on an Ubuntu EC2 small and I'm curious if the 1.5GB RAM isn't enough and THAT'S why pushpoold keeps quitting out after using up all the memory.
Right now my pushpoold is using about 20 MB of memory, and I don't see why it would need much more than that. The Litecoin client, on the other hand, needs a good amount of RAM to run, often over 100 MB. But even if we add to that the memory needed to run the database and a webserver, 1.5 GB is a lot. |
|
|
|
Would this be easy for someone to do? I really want it!  Sure thing: http://address.litecoin.net/Thanks goes to Greedi for putting it together. How established is the idea that Litecoin private keys start with "6"? Does Litecoin accept Bitcoin private keys? Pretty well established. Pywallet (jackjack's fork, which also works with Litecoin) and Vanitygen both conform to this. The latest version of Litecoin does not accept Bitcoin private keys; it only accepts keys starting with "6u" or "6v". |
|
|
|
Here is an example batch file for Windows: http://pastebin.com/RNNMBp2JIt was written by a miner I met on IRC. Since he doesn't have an account on this forum, I'm posting it for him. |
|
|
|
The pool is under heavy DDoS attack again. All miners who still haven't set up automatic failover to other pools or to solo mining are encouraged to do so as soon as possible. |
|
|
|
Litecoinpool.org now still hold 30% hash rate, which is still pretty high.
Because attacker love ddosing litecoinpool.org as primary target, my suggestion is to raise the fee a bit to 6.5% and use the 1.5% fee to get a better server, if possible or as emergency funds if something bad happened (mining pool get hacked).
With 6.5% fee, maybe some people will move to other mining server or create their own.
You can reduce the fee back to normal again after things back to normal - more mining pool created, or some people leave to other server.
There are a lot of CPU miners at litecoinpool.org (which makes sense, since most of the other pools have moved to a fixed lower target), so I don't feel like increasing the fee further. But! There are already two other public PPS pools out there, and both have lower fees than this one. They are notroll.in (4.8% fee) and Xurious's (3% fee). Both seem to work well and are run by serious and competent people, so I invite all GPU miners to give them a try. |
|
|
|
You guys lost a lot of business because of this DDoS attack. I couldn't get to the website or use it reliably for last two weeks.
Attack started on July 18, and stopped on July 23. The pool has been hashing without major interruptions since then. My total hashing power is over 1mh. Not great, but not minor at this point in the game. I'm sure you lost a good bit, and I REALLY hope you guys have some sort of resource to take legal action. At the very least, you can make your attacker(s) public if you know what happened.
Unfortunately I have no proof to convict the attacker. Also, has your pool upped it's share target yet?
This pool has been serving variable-difficulty targets for over a month, and I've received very positive feedback from miners about that. If I just increased the share difficulty (which means lowering the target), the speed estimates of slower miners would become very inaccurate. That's why some time ago I decided to start serving work with a target that is appropriate to the speed of the miner asking for it. This doesn't affect your rewards in any way, since shares are weighted, and counted according to their difficulty. On the other hand, it allows to keep accurate worker statistics while drastically reducing bandwidth. Best of both worlds.  I used to get errors/stales with reaper at litecoinpool that I didn't with Ozcoin.
Ozcoin only changed their share target a week ago, so your problem may be unrelated to this. I like the PPS better, and would like to switch, but I don't want to go to work/bed and find out that my miner sat for 12 hours+ doing nothing again.
You should not have to worry about that. Just setup failover options and relax. |
|
|
|
how did you manage to compile cpuminer on raspberry pi. i am stuck with these errors: pi@raspberrypi ~/cpuminer $ ./configure CFLAGS="-03"
checking build system type... armv6l-unknown-linux-gnueabihf
checking host system type... armv6l-unknown-linux-gnueabihf
checking target system type... armv6l-unknown-linux-gnueabihf
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in `/home/pi/cpuminer':
configure: error: C compiler cannot create executables
See `config.log' for more details
It's "-O3", not "-03". |
|
|
|
I have the same error  And I had to delete folder database to make the previous version work again. That may happen to you too, so do this in that case. Nothing has really changed from the previous release. You may want to build with IPV6 disabled. Please check the build readmes for how to do that. I tried the latest binaries and got the same error. I tried building without IPV6 and it STILL gave that other error. As I've already said, I got the same error with the latest bitcoind, and to make it work I had to disable IPv6 and patch bitcoinrpc.cpp. Commenting out lines 2664 to 2681 (inclusive) is a quick and (very) dirty fix. |
|
|
|
Is something wrong with the pool?
It accepts shares, but blocks are not confirming.
New litecoin client was released. They may need to upgrade. Until they announce they've upgrade, I'd move to another pool. Upgrading is certainly a good idea, but blocks should also confirm without the latest patch. |
|
|
|
Then I tried building it for myself: An error occured while setting up the RPC port 9332 for listening: open: Address family not supported by protocol
It seems any port I choose as a server for solo mining brings up that error. The only time I got that error was with an old Linux kernel that didn't support IPv6. I tried building bitcoind and it gave the same error. Once I undefined USE_IPV6 and fixed bitcoinrpc.cpp to completely avoid IPv6, everything ran fine. |
|
|
|
Any update? or is this pool dead now?
Not at all. Pool has been hashing as much as allowed by the recent DDoS attacks. |
|
|
|
Hate to bump an old thread, but I'm setting up a pool and I have everything working. My shares are being counted an all, but the only problem is my hashrate isn't being reported on the site at all. Any help?
Do you mean it is reported as zero? Bitcoin frontends usually display hash rates in MH/s, so that may be the cause. |
|
|
|
So, perhaps a lower level question. I cloned ArtFortz's pushpoold git and built it on Ubuntu and it would seem that this version has a memory leak?
My friend and I are doing a private pool to combine our resources and I can't seem to keep pushpoold up for more than ~48 hours before it just quits out with no error message. Over that time period, I can see it using more and more memory.
Anyone experienced this? Any ideas?
I've never found memory leaks in pushpool itself (kudos to jgarzik), but it is possible that the issue you are experiencing is caused by one of the dependencies. Some versions of libevent, in particular, are affected by memory leaks, so try upgrading it. |
|
|
|
If this is just synflooding there are some simple iptables rules which might help you. It will increase overall latency but at least you can get back to work.
Unfortunately it's not that simple. The pipe to the server is filled by DDoS traffic. People on IRC have been suggesting various solutions, but none of them is viable. |
|
|
|
Still Ddos attack going on?
I cant connect to site for the past 2 days
Yes, the attack is still ongoing. |
|
|
|
Digging up an old thread because my question is related  So PPS for a target.bits 17 pool would be: 50(32768/difficulty) Correct? My logic being 2^16 is 65536, and 17 would be half as many shares required. No. The higher target.bits, the lower (harder) the target. If on average it takes 2^17 hashes to find a share, the PPS rate would be: 50 LTC / (2^32*difficulty) * 2^17. The "2^32" part comes from the definition of difficulty: at difficulty 1 the expected number of hashes to compute in order to find a block is 2^32. |
|
|
|
Here is info from the Litecoincash pool thread... Speeds are now back to something more usual staying a bit higher as we setup 21 target
Translated to English: they use a target with 21 trailing zeros (in binary notation), i.e. in hex 0x000007ffffffffffffffffffffffffffffffffffffffffffffffffffffffffff (big endian) This is the lowest target I've seen so far on a Litecoin pool. |
|
|
|
ArtForz's fork is easier to setup, as it doesn't require external notification for long polling, and has a configurable share target.
alexhz's fork includes Cryptomaniac's patches, which for instance add support for local work generation. On the other hand, long polling needs to be setup as in the original pushpool, and the share target is fixed.
Thank you, appreciate the input! Making sure I'm understanding this correctly, the alexhz version takes the work generation load off litecoind? But the artforz version you can reduce the load by altering the share target? (and thus processing less shares/second) Yes and yes. |
|
|
|
|
ArtForz's fork is easier to setup, as it doesn't require external notification for long polling, and has a configurable share target.
alexhz's fork includes Cryptomaniac's patches, which for instance add support for local work generation. On the other hand, long polling needs to be setup as in the original pushpool, and the share target is fixed.
|
|
|
|
|
Show Posts
