Hey, great to see you're adding new coins. Your site is a lazy armchair miner's delight. Also, the sha256 coins such as PPC will be a great addition.
I saw this: 2013-07-07 03:58:16 LKY, ARG and PXC are now available for BETA testing. Use pool1.us.multipool.in rather than the normal hostname!
and I saw that these new coins will only be available for multiport after BETA. What about during BETA, is multiport on for all these and other coins combined? I'll switch to beta right now if so.
Thanks!
Port 7777 on pool1.us is currently just pointing at LTC. |
|
|
|
Can't connect to nvc pool again  The pool is up, can you let me know what error you are getting? |
|
|
|
|
If you are direct mining a coin, please try the new load balanced pool at stratum+tcp://pool1.us.multipool.in.
These are much higher capacity machines and should not suffer from stratum disconnects like the current pool does when load gets high.
|
|
|
|
My confirmed LTC balance is suddenly negative (-0.2182).
I paid the last block twice by mistake. I had to unpay it. |
|
|
|
Hey, great to see you're adding new coins. Your site is a lazy armchair miner's delight. Also, the sha256 coins such as PPC will be a great addition.
I saw this: 2013-07-07 03:58:16 LKY, ARG and PXC are now available for BETA testing. Use pool1.us.multipool.in rather than the normal hostname!
and I saw that these new coins will only be available for multiport after BETA. What about during BETA, is multiport on for all these and other coins combined? I'll switch to beta right now if so.
Thanks!
Currently no, the beta coins are only available for direct mining at the moment. |
|
|
|
|
The last 5 DGC blocks (212374 - 212273) were paid, however they have no payout data available due to a sql issue in the db..
|
|
|
|
Just wanted to add my +1 for MEC on the multiport. Thanks for your efforts Mr Flound
still thinking about it.. I took a look at their thread(s) today and it seems like the devs don't really have their shit together. But I will consider it. |
|
|
|
pool maintenance starting now, eta 5-10 minutes
maintenance complete |
|
|
|
|
pool maintenance starting now, eta 5-10 minutes
|
|
|
|
At the suggestion of one of our hero members, I am switching from fixed Last-N based payouts to time-based payouts. I think it makes a bit more sense considering the nature of our pool.
I am setting the following time periods for each of the coins currently on the pool:
LTC: 24 hours
TRC: 6 hours
FTC: 8 hours
MNC: 30 minutes
WDC: 30 minutes
DGC: 30 Minutes
NVC: 12 hours
Please respond with any comments or concerns.
I don't completely understand the implications myself yet, but I had a vague feeling that time-based PPLNS had some problems, and the PPLNS thread seems to confirm: The most naive implementation is to have a fixed N and simply pay the last N shares equally. However, this makes it more profitable to mine before difficulty decreases, and less profitable before difficulty increases - the number of blocks that are expected to be found in your window depends on the future difficulty, while the payout you can receive elsewhere depends on the current difficulty.
It doesn't help if N is chosen to be a given multiple of the difficulty at the time a block is found. If the difficulty is about to increase, it is more profitable to mine a short while before. For example, if N is set equal to the difficulty D, a share submitted D shares before the increase will be paid the full expectation in the D-window, and then when difficulty increased it will once again go inside the window and have more expected reward. And, like the previous case, shares submitted just before the difficulty change will be rewarded similarly to shares submitted after it.
Another incorrect implementation is to pay all shares in a window given in units of time (sometimes called PPLNM or PPLNH). In addition to the problems above, it has a problem common to all reward systems that use time as a factor, which is that it is more profitable to mine when the current hashrate is higher than the average.
Now that I'm actually mining on a pool which uses this method, I might give it more thought, and perhaps understand the problem. Not a lot of money at stake here, and I don't mind being motivated to do some research  Shift-based PPLNS would be the best PPLNS implementation based on that thread. It's used on BTC Guild and BitMinter. Well, the problem is that our pool is different from the others in that there is some inherent 'hopping' involved in just using the pool (for those on the multiport, anyway). We need to strike a balance between paying the multiport users fairly and also paying the dedicated coin miners fairly. |
|
|
|
|
At the suggestion of one of our hero members, I am switching from fixed Last-N based payouts to time-based payouts. I think it makes a bit more sense considering the nature of our pool.
I am setting the following time periods for each of the coins currently on the pool:
LTC: 24 hours
TRC: 6 hours
FTC: 8 hours
MNC: 30 minutes
WDC: 30 minutes
DGC: 30 Minutes
NVC: 12 hours
Please respond with any comments or concerns.
|
|
|
|
Was there some hashing on NVC that didn't get credited? Just askin but I was having network issues so that might have affected my outcome.
Yes, the last 3 blocks on NVC were scored incorrectly, they have been re-scored and repaid. |
|
|
|
MNC server seems like it may be overloaded again. Manually switching to MNC pool instead of multiport worked for a little while, but not long... I've switched over to LTC again manually in the mean time.
I tried setting the diff to 16 for MNC so we would get fewer stales, but it's too much for the server to handle when the multiport is on it.. Once we move to the two load balanced servers this should no longer be an issue and I would expect we will be able to scale well past 2+GHash on the scrypt pools. Why do you think that the share difficulty would have an effect on stale rates? AFAIK, it just has an effect on the variance of stales rates. With a higher difficulty, it's less likely to get rejects on block changes, but the rejects that do happen have more impact. This should result in exactly the same stale rate, no matter which share difficulty is used. When the block changes, the current share being worked on is abandoned and if submitted it's rejected. Since the miner submits target 16 shares (approximately) twice as fast as target 32 shares, reducing the difficulty should result in the same number of stales, but the percentage of stales should be half since the total number is higher. The unavoidable latency between issuing a work restart and a miner receiving it results in a small window where the miner is effectively working to produce stale shares. Some devices (like BFL ASICs) also have additional latency on restarts, but let's ignore that. The latency window is always the same, no matter which share difficulty is used. If a miner is using diff16 shares, the probability of producing a stale share is twice that of another miner which is using diff32 shares. Not the same, as you are implying in the bolded part of what I quoted. Reducing share difficulty makes it more likely that stale shares are produced during block changes, because the chance to produce a share that matches the target during the latency window is higher. But since all shares have lower value, expected total stale difficulty is the same. Hmm, I'll have to think about this more, but I see what you are saying |
|
|
|
MNC server seems like it may be overloaded again. Manually switching to MNC pool instead of multiport worked for a little while, but not long... I've switched over to LTC again manually in the mean time.
I tried setting the diff to 16 for MNC so we would get fewer stales, but it's too much for the server to handle when the multiport is on it.. Once we move to the two load balanced servers this should no longer be an issue and I would expect we will be able to scale well past 2+GHash on the scrypt pools. Why do you think that the share difficulty would have an effect on stale rates? AFAIK, it just has an effect on the variance of stales rates. With a higher difficulty, it's less likely to get rejects on block changes, but the rejects that do happen have more impact. This should result in exactly the same stale rate, no matter which share difficulty is used. When the block changes, the current share being worked on is abandoned and if submitted it's rejected. Since the miner submits target 16 shares (approximately) twice as fast as target 32 shares, reducing the difficulty should result in the same number of stales, but the percentage of stales should be half since the total number is higher. |
|
|
|
MNC server seems like it may be overloaded again. Manually switching to MNC pool instead of multiport worked for a little while, but not long... I've switched over to LTC again manually in the mean time.
I tried setting the diff to 16 for MNC so we would get fewer stales, but it's too much for the server to handle when the multiport is on it.. Once we move to the two load balanced servers this should no longer be an issue and I would expect we will be able to scale well past 2+GHash on the scrypt pools. |
|
|
|
|
Alright, I am setting up LKY, ARG and PXC on a set of 2 new, load balanced pool servers. After testing, these three coins will be *multiport only*. I.E. you won't be able to mine them directly.
ETA for testing is tonight. Tomorrow I hope to add PPC and FRC.
|
|
|
|
If you're going to complain about how big of a scam a particular scamcoin is, NVC arguably shouldn't have been added.  Personally I don't care about the origins of the coin, most of them are pretty similar in that regard. What I'm interested in is anything that will help boost our effective profitability. Well, yeah, but NVC only had a 110,000 coin premine which was (supposedly) destroyed, many of the newer coins have much much more than that. The PXC premine was supposedly for bounties, but how much of that has actually been given out? |
|
|
|
Do you guys still want NVC in the pool? It takes several days to confirm blocks but the price is very stable so it shouldn't be a concern.. Let me know what you htink.
NVC can stay as far as I'm concerned. As you mentioned yourself, the price is very stable so you should get about the same rate by the time your coins are transfered for trading. How is your work coming along for adding PXC and other coins? You guys really want PXC? You know about the million coin premine right? |
|
|
|
|
Similar problem to what happened the other night but not exactly the same.. Things are fixed now and again no shares were lost.
|
|
|
|
What about payment of block LTC 383883
It's been paid out now. |
|
|
|
|
Show Posts
