Topic: [ANN][The Original Multipool - Scrypt/SHA256/Scrypt-N/X11] multipool.us - page 135. (Read 424232 times)

i've posted this before, got no response or pm.

Payout WDC not received, please take a look operator. Thanks in advance. 1st time this happend.

WDC   Sep 09 1:36 AM   WVsH8brNvzbwUupkwqsiTADN54KYvgsvEz    448.34474454

flound1129 if you can look at my cousin account( noname ), he say there is a balance in CGB and DGC that stay "unconfirmed" .

Thank you

MEC has been removed from Cryptsy so yes it should be disabled.

Flound, you may want to keep a close eye on MEC, and maybe even disable it for a little while:

https://bitcointalksearch.org/topic/m.3141858

Because that's what I said I was going to do.  Over longer time periods it should even out, anyway.

I'm currently looking for ways to decrease our LTC variance, but I've run into a few roadblocks.

So why re-enable it then?

There is no longer a minimum withdrawal for LTC.

It was definitely better without LTC.

I have LTC balance I need to add/clear for withdrawal.    LTC favours slower ping times over the fast block coins, so some will prefer more then others

And what did the test reveal? Wasn't the profitability that much better without it?

A lot of orphans from cgb aswell...

I too am experiencing less than 50% efficiency reported on DGC.

as of 10min ago:
10 Minute Hash Rate   540 Kh/s
Valid Round Shares   1920
Invalid Round Shares   2048
Your Efficiency   48.39%

As of now:
10 Minute Hash Rate   533 Kh/s
Valid Round Shares   1408
Invalid Round Shares   2304
Your Efficiency   37.93%

My client is reporting only slightly higher than average rejects (12% over last 10min)

I'm using pool1.us.multipool.in:7777
relevant settings: 19 intensity,  gpu-threads 1, worksize 256, thread concurrency 24000, 1050/1500 core/mem (1x7950)
rest is default (cgminer 3.4.2)

When I disabled it I said it was only for 48 hours as a test.

LTC is now re-enabled on the Multiport? When did this happen? Did I miss something?

I'm not really sure what's going on with DGC, we're also getting tons of orphans.

I updated earlier today.

You consider it a good thing that as soon as it is hit with any amount of hashing power, the difficulty will explode and make it un-minable?

Oh, and your MEC block explorer is down.  500 Error.

First of all, Flound needs to update the profitability calculation to use 75 coins instead of 125 coins at the right time.  Coinchoose and Middlecoin will have to do the same thing.  Otherwise, one of them will grind your profitability down to 60% of other coins.  If you don't believe me that this is done manually, scroll through the multipool and coinchoose threads and see how many times the developers have to be told of the change.

Looking over the new algorithm for MEC, I don't have a lot of hope for MEC.  It looks like a clever developer trying to be too clever, and I think the result will be bad.

As I understand it, the algorithm works like this:
Next Diff = (Average Diff over the last N blocks) * (150 seconds) * N / (Actual Seconds for last N blocks)
where N is a number between 144 and 4032.
The "clever" part is that N gets smaller when the diff changes quickly and N gets larger when the diff is stable.  The idea would be that when there is a quick change in hash rate, it reacts quickly.  When the hash rate is stable, it reacts slowly.

The problem is the first part of the algorithm has momentum.  This is one of the things that caused so much trouble with the transition at block 42,000.  Even after the MP switched off around block 42130, the difficulty kept climbing for about 70 more blocks (which took 2 days).

For example, if N is 144 and the coin-hoppers mine a fast 50 coins and switch off the coin, those coins will still be counted in the average used for the next difficulty while the faithful have to grind on 94 coins themselves.

The change in direction will also increase N, causing the permitted change to be smaller, and allowing those 50 fast-mined coins to linger even longer, forcing the faithful miners to spend even more time trying to create even more blocks necessary to bring difficulty back down.

The idea was clever, but not practically applied.  If instead of using block counts for PastBlockMin and PastBlockMax, he had used Time (i.e. PastSecondsMin and PastSecondsMax), then used blocks/hour instead of hours (seconds) per block for the calculation. That way if the coin slows down to 2-4 blocks per hour, it doesn't take days of grinding to get the 50-100 blocks needed to push the fast blocks out of the window of consideration.

Hopefully, I am wrong and it stays profitable to mine for the faithful and keeps producing blocks.  Unfortunately, I think that every time it gets marginally profitable to mine, MP, MC and CC will slap it down and create problem like it had with block 42,000 where transactions don't confirm and 2 guys are stuck mining it for days waiting for it to recover, only to get slapped down and have to repeat the cycle.

To be honest, the simplest solutions are often the best:
Retarget every block
Diff Adjustment = (Target Seconds for last 10 blocks) / (Actual Seconds for last 10 blocks)
If (Diff Adjustment < 0.99) New Diff Adjustment=0.99
If (Diff Adjustment > 1.01) New Diff Adjustment=1.01
New Diff = Last Diff * Diff Adjustment

Coins that make frequent small adjustments have been the ones that have dealt best with Multipool/Middlecoin/cgwatcher.  They tend to stay very profitable all of the time, and then build up a strong base of dedicated miners which stabilizes their hash rate.

Flound, do you have multipools MEC client updated?

Yup, we should be good on the flip this time .   It will make megacoin more "hop" resistant, as well.  Multipool is only going to mine it when its profitable based on the price, the difficulty won't matter.  It may actually cause some problems for multipool because it will only be able to mine a few blocks before the difficulty quickly adjusts.