Quote from: os2sam on June 05, 2013, 10:19:17 PM

Quote from: eleuthria on June 05, 2013, 01:27:30 AM

Quote from: os2sam on June 05, 2013, 01:16:24 AM

Quote from: pikeadz on June 05, 2013, 01:04:25 AM

This will really help with the difficulty spike eating away profits. Thank you for doing this.

It usually cause severe Bitcoin mining instability. I'm not at all happy about this.

Merged mining doesn't cause instability unless the implementation is poor. It can cause minor (<0.1%) drops in BTC due to added latency when preparing new work after a longpoll. However, I'm specifically implementing this in a way where namecoin efficiency is sacrificed to let the pool run without skipping a beat even if namecoind is frozen/slow/crashed. The only efficiency change will be work messages from the pool require ~50 bytes of extra data inside the coinbase.

UPDATE: Phase 1 went well. I've got the pool creating the bitcoin side of merged mining (coinbase message that includes the mm signal + namecoin block hash) while still successfully creating blocks. Tomorrow I'll be working on building the NMC block with the MM headers included. It's very likely this can be done by the weekend unless I run into unexpected problems. Everything is in place so the entire namecoin side is running in a separate thread that will not block the primary pool/bitcoin threads.

Putting aside my general dislike for merged mining for a minute, maybe

.

What is unleashing 30 to 40T(Terra)Hash/s on Alt Coin chains going to do to them? Is it going to make the alt coin miners happy campers?

Just wondering.
Thanks,
Sam

Ofc not, we're increasing network hash rate dramatically.

Request: Can we set "display units" as a default across all pages? I have 7 active workers and have to keep expanding it to show more each time. I can also see on slow page loads that it does load them all, just hides them again.