Sorry, I don't get the picture. We were testing merged mining on different smaller setups on testnet. Slush for example supported testing with having his rigs mining on masterpool alpha.However AFAIK no one paid out testnet coins (well masterpool alpha did, but there was no real demand) merged mining started on block 19500. NMC community agreed on starting earlier after the hashing power on NMC blockchain faded from day to day. AFAIK slush even started some time after merged mining started on non-testnet as there were scalability issues with mm proxy.

We were eager to test merged mining and thus set starting block number on testnet to zero  (http://dot-bit.org/forum/viewtopic.php?p=1555#p1555)

Mhmm, so you are suggesting we should have started threads discussing the implications of merged mining two month before starting like: BTC/NMC merged mining available for testing (https://bitcointalk.org/index.php?topic=29074.0)?

or should have offered a testing pool at least one and a half month before starting like: [ALPHA.masterpool.eu] Merged Mining Test Pool - TESTNET - BTC & NMC (https://bitcointalk.org/index.php?topic=33247.msg416091#msg416091)?

Try to find the error 

  Now I undestand. You just didn't get the whole picture. Please try to read dot-bit forum at first and understand the motivation of merged mining. Just one hint: No namecoin user which was really interested in NMC has a problem with slush mining at 2THash/s. It's quite the contrary. It was intended to get as much pools on board as possible to overcome the problem with way too less hashing power on the blockchain. We were even afraid of not getting enough hashing power. Thankfully slush helped out with this problem. Thus everybody following the posts on NMC forum did know, what was going to happen.

Oh c'mon. What's your point? It's one thing to say slush should have done an opt-in beta as eleu suggested or to say it was a rash decision to post about some other pool having some correlation to the source of the DDoSes. Perhaps it was emotional and written with way too less sleep. We can talk about that and I guess the two persons in question already did that with the nessecary professionality. At least they are not mud-wrestling on the forum. However this are things you might criticize and all other may contribute to this discourse if you think its still nessecary.

But IMHO its something else to oppose slushs reputation and his integrity regarding payouts of his pool. It doesn't seem opportune to accuse someone of something which can be falsified with a look at the block explorer.

I can report, that slush already told me that he is going to pay his members the merge mined NMC even before he had implemented merged mining. That was at times of BCXs upcoming 51% attack which never happened (http://dot-bit.org/forum/viewtopic.php?f=2&t=308). But of course you are right its only my word and i can not proof it. However, sorry to disapoint you, but there was someone else faster unveiling the fact that slush and me are working towards total world domination with all Bitcoin users being our evil minions (http://dot-bit.org/forum/viewtopic.php?p=2106#p2106). This is going to become a great conspiracy theory! Let me get my popcorn ready!

Some time ago I started a survey asking if MasterPool should change its reward type. Now the survey has been evaluated. Here are the most important points in a nutshell:

MasterPool will be changed into a PPLNS pool within the next weeks. Furthermore I won’t implement a PPS option. The most used ingress server is EU01. Thus if I need to dismantle one mining ingress server due to too low usage it will be US01. However if BTC prices rise again and MasterPool needs further ressources then the next server will be added in Asia right after the US followed by Australia.

Please find all information and the results of the survey on MasterPools blog: http://blog.masterpool.eu/2011/10/masterpool-member-survey-102011/

www.MasterPool.eu was the first pool which implemented merged mining. (I already had a pool running on testnet during development). However we had some major performance issues recently (http://blog.masterpool.eu/2011/10/the-quest-for-performance/). However thanks to the feedback from the community all severe issues have been sorted out and we are back to the low stale ratio from pre merged mining days.

Please have a look at the blockstats if you like: https://www.masterpool.eu/statistics/blockhistory

Today I got hands on a Windows PC and installed the latest version of GUI miner. However I only had the possibility to use CPU. But I guess this shouldn't make any difference for testing connection issues. It connected without a problem hashing at about poor 8 MHash/s. I waited some long polls and submitted a share. Is anybody out there who can confirm this issue?

Thank you for testing. I'll install some Windows to my Linux Box and try to reproduce it the next days. Honestly I don't undestand it, as last poclbm is running fine under linux. I have reports that it is working on windows without flaws as well. Perhaps this is a GUI miner speciality.

I made a big bunch of improvements to the pool (have a look at the blog: http://blog.masterpool.eu/2011/10/the-quest-for-performance/). The pool is again running smooth with very low stales. Furthermore I fixed some stuff that should make it better compatible with newer versions of mining software. If you have the time would you mind to test again with your current version of GUI miner?

BTW. Did a mod change the topic or am I getting paranoid 

Mhmm, that's really strange. I'm not using guiminer. But after the database had some time to settle I'm now getting pure accepts from my miner. Don't know if you still care to sort out this problem. If yes. Is this problem occuring occasionally while mining or is it even impossible to connect to the pool? In the latter case have you chosen the right port? Unlike most BTC pools MasterPool uses port 8888.

As mentioned before I don't know much about GUI miners (as I'm using Linux). But poclbm has a neat failoverfeature. Perhaps you might want to give it a try?

In most cases I'm quite confident that rollouts run flawles as I'm using only cfengine in order to administrate production servers  Unfortunately it doesn't prevent stupid mistakes while designing a database layout. Such as plugin would've come in handy.  

Welcome back. Pool is back online and operational. Downtime was about 18 minutes. Thank you for your patience. Happy mining!

Yeah, I'm sorry  I guess this is related to the problem above. It should be fixed after the rollout.

With the recent amount of new users the pool faced a massive problem with high stales and was responding very slowly. I analyzed the problem and found out, that the database is the bottleneck. I prepared a solution but it means a major downtime for the pool. In order to circumvent the bottleneck I need to split some tables. This however took about 30 minutes on the testing mashine. I guess it'll be the same for the production database cluster (perhaps a bit more, as they are synchronizing themselves). In order to get the pool back on track. I'd like to roll out this update very soon and apologize for this short announcement. But as the pool sometimes stops responding for some seconds anyway I guess it's better to address this ASAP.

I'll start with the rollout at 8 pm UTC.

You may want to switch your miners to another pool for this time or make sure you have configured a failover pool.

No, it's not condoned (as this would imply that a customary right might be derived in future). At the moment however it's a fact that it's technically possible to hop pools with MasterPool. Furthermore I have no bullet proof possibility to know for sure if someone is pool hopping or if it is coincidence (however there is a strong evidence that some miners are doing it). But as long as I have no possibility to proof someone is pool hopping it wouldn't make sense to prohibit it. For that reason it is tolerated at the moment, as long as it happens in an acceptable manner (acceptable in terms of not disturbing the pools performance).

My current focus is on having a bunch of merge mined BTC being verified, awarded and sent out to the miners. If I'm confident there is nothing else to tweak I'll have the registered (and active) members decide whether or not we change the distribution scheme. I tend to not go with proportional payouts and I have quite some requests from miners to change it. As soon as we have a decision on this all pool members will be notified via email with at least one week time to change pools if they don't like the new scheme.

MasterPool at your service, Sir! 

Maybe you missed the announcement on dot-bit.org some time ago? JSON Stats moved to: https://www.masterpool.eu/jsonstats and includes BTC stats. /api is obsolete and will be removed in future. Have a look here for description: https://www.masterpool.eu/faq