bitcoind and namecoind both slowed down at the same time. There's some sort of issue there. Pool recovered after a couple of minutes though.

juhakall, a 4/4 difficulty proof being rejected sounds strange.. I'll have a look at it. This was with Stratum?

It's working for me. It's just a redirect, so 5050 and 3333 should be up/down at the same time.

Need to restart bitcoind and namecoind. They take a while to get up and running again, sorry for the delay..

Hall of fame is on my list.


Could be because your miner stayed at a backup pool or that it crashed when it was disconnected by the server. Some miner programs have been having those issues lately.

Turbor, your explanation is as good as any I can come up with.

Looks like all I/O got slower and slower. After a while some getwork requests took 5 minutes. The database connections terminated with "end of file" and it was impossible to establish new ones. syslog tells me the web server got stuck for over 120 seconds waiting for a page from disk. But there is nothing wrong with the disks. The pool server had several hundred thousand closed connections that somehow the kernel stopped clearing away. The load was 25-30 with almost no cpu usage. Apparently all these processes were waiting on IO. I could still send a request to bitcoind or namecoind and it would register in their logs but no response would come out. After restarting each process everything is fine. It's like the kernel just wouldn't honor IO requests from the "old" processes. I've never seen anything like it.

So yes, maybe it was the ghost in the machine.

I'll be working on robustness and automatic recovery, although I hope not to see this type of behavior again.

Back up again... sorry for the downtime

Not namecoin this time. Something strange going on, will need to investigate further.

Something wrong, working on it.

Sure, that's what I was going to do.

And yes, namecoind has configurable ports just like bitcoind. In fact the config file is named bitcoin.conf. I think in the latest namecoin versions you are allowed to rename the file to namecoin.conf. But I always thought it was silly they didn't even bother to change the name "bitcoin" everywhere.

It always gave me the impression: "Dude, you should totally invest in my coin. I spent like 10 minutes renaming bitcoin. Oh, I may have missed a couple places, but it's an awesome coin!" Actually I get that impression from all the "alt coins".

Some instability this morning due to an insane spam of getwork requests from some miners. This has happened a couple times lately. I may have to work further on protecting against this. Perhaps block the IP address in the firewall for 5 minutes if you request too much work too quickly.


Bitcoin difficulty is 3.5 times higher than namecoin, and after the reward halving bitcoin makes roughly (not considering tx fees) half the coins per block. So namecoins are produced 7 times as fast as bitcoins. Right now I see namecoins sold 216 for 1 bitcoin. 7/216=0.0324... So namecoins give a 3.2% extra income.

3.2% extra income is a major feature for my pool, so I'll keep it if I can.


Yeah, and anything you type gets echoed back to you, as the socket is connected to itself. A really annoying "feature".


I'm going to do the second, as it is the quickest. But maybe I'll do the first as well. If source and destination ports are the same and you are connected to localhost, immediately disconnect and consider it the same as a failure to connect.

The last downtime looks to be the issue with the socket connecting to itself after namecoind goes down. That's the second time this has happened.

namecoind is being monitored and will attempt to restart. But in the meantime the pool keeps retrying to establish contact with namecoind. If namecoind doesn't come back up soon enough it can happen that Linux picks the source port to be the same as the destination port, as I attempted to explain in the previous message. Then the pool connects to itself and gets a bit confused. Also namecoind is unable to start after that because the port is already in use.

I can work around this issue so it won't happen anymore. I will also make the pool service more robust (regarding crashing coin backends) and add a semi-intelligent automatic restart of the pool service if it ceases to function properly.

This should allow to keep merged mining of the unmaintained and constantly crashing namecoin, without the stability issues for the pool. I can hear some of you saying "just kill namecoin". But as long as they are a decent income boost it makes sense to keep them, right? That's assuming I can isolate the bugs in namecoin to just the namecoin side of mining and keep the pool itself stable.

I do fear namecoin is dying though, after all its developers abandoned it. To all developers making me-too coins: become a namecoin dev instead, it makes more sense.

Apologies for downtime earlier today. I was away and had to use a cell phone to get things going again. Haven't really been able to investigate the issue much yet. But it seems to be running smoothly again after the restart. What I can say is that namecoind had crashed (as usual), but there must have been something more wrong.

Today's insight into networking magic for the techies:
One weird new thing I have learned about Linux/TCP lately. If namecoind is down and a process tries to connect to it, then Linux may pick the destination port to also be the source port for the connection. If this happens when connecting to localhost then the socket will connect to itself. Yes, even though you were connecting, not listening. After that the pool thinks it is talking to namecoind, but for every HTTP request it sends it doesn't get an HTTP response back, it gets its own HTTP request back. It is talking to itself. A real pain, and very odd behavior by the network stack in my opinion, whether it is by TCP specs or not.

Sorry, a technical issue made the pool unstable (many failed connection attempts if you didn't already have an active connection). Now fixed.

Sorry that I added to the spam. But there is a reason these forums are so unfriendly. kano has a habit of trolling, name calling, religious harassment, etc. etc. I don't know why he hasn't been banned yet. But if noone says anything, things won't get any better.

What ckolivas said. My point is that ntime doesn't need to be exact to the second. We could require every miner to own their own atomic clock, but why bother.


Maybe I missed something, but from what I can see the Stratum spec only says you get an ntime from the server and you send one back. I can't find where it says how you should treat this value?

Maybe I misunderstood you, kano.

So are you saying that an inaccurate ntime is fine and you must never touch ntime (let's call it the "magic token") after you got it from bitcoind?

Or are you saying that inaccurate ntime is harmful for bitcoin? Let's call it the "kano attack". By that logic would you also say that cgminer is becoming just another miner that people should avoid using? Maybe look at bfgminer or poclbm in hope that they are less harmful to Bitcoin? I mean you often recommend people to not use other products and services for much less serious reasons. What if your own product can destroy Bitcoin?

There's always the third option. You know that I'm right, you just like to write a lot of words.

You have to store the merkleroot and the extranonce2 bytes at least until you submit all proofs of work based on them. After that you could free them, but you will need to reallocate that memory to create new work in less than 1 second. It's better to keep those few bytes of memory sitting there until the server gives you new work, rather than constantly free and reallocate those tiny memory fragments.


In the BitMinter thread I suggested rolling ntime in sync with the clock and reusing work, but you protested vehemently against any modification to ntime. And cgminer does indeed stick with the old (now inaccurate) ntime it got from the server. Yet you also said an inaccurate ntime is bad.

Riddle me this: How can a clock never change and yet be accurate?

Sorry for the short downtime. There was an issue with bitcoind which had to be restarted.

To get the most accurate ntime you can roll it forward by 1 every second. Then you can reuse all your merkleroots again.

Or if you insist, like kano, then you can stick with the old ntime value and throw the merkletrees away and recreate them again for no reason.
But please keep in mind that such an inaccurate ntime is bad for Bitcoin.

Cool to see this going public.

Good luck BitFunder!

My goal is for BitMinter client to work with BFL SCs from the day you receive them. If I don't have time for everything then that will be with getwork with rollntime. That's good enough for running ASICs. It doesn't allow you to inspect blocks like GBT or give you the low bandwidth usage of Stratum, but it certainly works.

When it comes to bASIC it looks like I won't have remote access to any units until miners have them. It also looks like it will be more complex to add support for them than the BFL units. That means if you ordered bASIC you will want to find a miner that will support them from day 1 so your bASIC doesn't sit idle.

Avalon, from what I understand, comes with a (tiny) computer with preinstalled software. You just plug it in and it runs.


I don't think I want to go there. The GBT versus Stratum discussions are bad enough. If you ordered bASIC then you will probably want to check the bASIC forums to see which miner authors they are working with to get support from day 1.