I can confirm that you probably have no idea what you are talking about, I run MOON as one of my pools and have no issues whatsoever....
Having run a mooncoin pool myself and a ton of other coin daemons currently that aren't causing any issue like mooncoin, I can confirm that you can gfy
Insulting others won't help the fact that you obviously lack the proper knowledge to run any kind of pool.....
You insulting me doesn't make this coin any less of a pile........
insults is all shitcoin lovers have. to da moon
The only one who is insulting here, is you. And mattle74. He did not even say sorry for calling Mooncoin a shitcoin/crapcoin. And I'm sure, you won't do either.
Mooncoin is fine. What is not so fine, are people that stumble into a thread, call a coin shit or crap and beat loose.
So I see your posting as a joke only - regarding your signature. Right?
I totally agree. It's a pitty that people don't put in some constructive efforts, if there's an issue ask the devs or the community and try to resolve it. There is one point that was made about bandwidth being used by MOON's daemon and I have to confirm this is correct, strangely enough it seems to be happening on the p2p port 44664, I see traffic between 5mb/s and 12mb/s where most coins only generate 500kb/s max. So it is definitely worth looking. This is still no reason to burn down MOON and it could have been resolved loooooooooong time ago if it would have been reported in a normal way.
I have now also checked that thing a little bit closer with network-metering. And can confirm the numbers that you state above.
Then I have found this:
https://bitcointalk.org/index.php?topic=153232.0 - see chapter:
Tune bitcoind and P2PoolIf you can't use the methods above or they aren't enough you can limit the number of connections used by bitcoind and P2Pool.
For bitcoind, use the parameter maxconnections in bitcoin.conf
maxconnections=10 # 125 is the default, don't go below 8
There's a compromise here: the more connections, the faster your node will be notified of new blocks and avoid wasting work, the faster it can include transactions with fees in the coinbase and the faster it will propagate a P2Pool block minimizing chances it would become orphan.
But the less connections, the less bandwidth used and the lower the latency.
More than 20 for maxconnections is probably overkill: from my experience (trying various values from 6 to 100) it seems there's not much gain to have past this value (and if you don't have enough WAN bandwidth it can hurt your latencies by queuing transfers between P2Pool nodes during peaks).
Note that this may change in the future if the behavior of bitcoind/P2Pool network changes: when in doubt, monitor your interface(s) bandwidth usage and raise this value when most peaks are below your link capacity.
If your orphan rate is fine, don't tempt the devil and try tuning maxconnections below 20: you may reduce your income more than you increase it...
Warning: P2Pool needs one connection to bitcoind and bitcoind tries to fill all the allowed connections after startup. If you start P2Pool just after bitcoind (or before, it will repeatedly try to connect), it shouldn't have problem connecting because bitcoind will still have connection slots available. If you set maxconnections too low P2Pool might not succeed connecting.
For P2Pool, you can do the same by passing parameters to P2Pool:
--max-conns 8 --outgoing-conns 4
Note: orphans will quickly rise if you have very few connections (they are the means to be notified of other shares after all). I would prefer reducing bitcoind connections before P2Pool's.
In my experience you can get as low as 6 total connections (3 in, 3 out) without noticeable efficiency changes. The default values seem overkill (6 outgoing, 40 incoming). The large number of incoming connections (--max-conns) is designed to help the whole network (some nodes are behind firewalls that don't allow incoming connections). You probably should allow more incoming connections (and check that your network setup allows incoming connections) to do your part in helping the network.
... and thought, the problem could really be, that the mooncoind "out of the box" is set to accept the mentioned 125 connections (or maybe even more here, as the instructions above are originally for bitcoind), if you don't use the maxconnections-parameter. So I tried to limit the maximum connections to 10 on port 9664 via iptables as a first measure and guess what, the bandwidth on port 44664 immediately dropped from ~14 MBit/sec. to 300 KBit/sec.
Therefore I assume, that starting mooncoind with the parameter to reduce the number of connections will have a similar effect. Could you try that? So that we can say, if you have problems with high bandwidth been used, reduce the maxconnections of your mooncoind, to resolve it ...
I'll try to start the mooncoind also with the parameter set, and report back.
Edit:
Tried it now, and it seems as if starting mooncoind like this:
mooncoin/src/mooncoind --maxconnections=10
... yields the same result, effectively reducing the used bandwidth dramatically.
Now we just have to check, whether this is problematic regarding accepting more than 10 miner-connections on a P2Pool.
