Merged mining is only a few blocks away now and from what I can see the bitcoin side of the equation is grossly underprepared. I hope I'm wrong but I don't think this is going to go well. The problem as I see it is that the merged mining community has prepared itself but not given the bitcoin community the tools it needs to adapt. Let me explain.
Documentation is woefully lacking. Basically limited to a wiki page a some scattered discussion threads on the namecoin forum. Miners don't need to do anything but bitcoin pools that wish to adopt merged mining need to implement the spec one way or another. Currently the only way to do this is to use vinced's patched bitcoind and namecoind along with the python merged-mining-proxy. This proxy has to sit between the poolserver (e.g. pushpool, poolserverj or custom) and the bitcoind. This represents both a potential bottleneck and an extra point of failure and to my knowledge has never been tested on a load greater than about 50GH. The alternative is for pools to implement the merged mining spec themselves. This is easier said than done. The spec is NOT documented anywhere. The limit of the documentation that I can find is this:
Parent blockchain (AKA bitcoind)
In order to verify that a client has done hashing on the namecoin blockchain it is nessecary to add a proof that the work has been done on the bitcoin blockchain to the namecoin blockchain. In order to make it possible to have this proof created by the bitcoin blockchain the bitcoind needs a patch. This patch makes it possible for the bitcoind to cryptograhically sign, that there there was work submitted to the namecoin blockchain as well.
Status: Patch ready for testing. Need to ask if it gets implemented to stock bitcoind
[edit] Auxiliary Blockchain (AKA namecoind)
The namecoind now needs to accept the cryptographically signed proof from the bitcoind.
Status: Patch ready for testing. Proposed for block 24000 (but still not agreed upon).
[edit] merged-mine-proxy
This is the daemon all miners connect to. The daemon itself knows how to connect to the bitcoind and the namecoind checking if shares are valid for one of its downstream blockchains. Furthermore it requests getworks from the parent (which must be patched, see above) and delivers it to the miners.
Status: Ready for testing. Implemented using python.
There is also an article in the bitcoin wiki by Mike Hearn that predates the MM implementation by many months but it at best it explains the general principles using quite a different example and none of the specifics.
For a protocol that involves talking to multiple chains, building merkle trees of block hashes in a barely defined order with extra fields that are defined but not actually used in the implementation, extracting merkle branches, parsing undocumented contructs of headers, parts of coinbase transactions and merkle branches and somehow using this to validate aux blocks where the parent block may not even exist... This documentation woefully inadequate, bordering on pathetic.
If someone wants to make an alternative implementation they have no choice but to pore over the source code in two different languages. I've done this, it took me days to get a grip on it and if weren't for ArtForz's considerable help it would have taken a lot longer. Even having done that there are a number of ambiguous issues that leave implementation decisions to be guessed at. Luke-jr has submitted a partial solution but has also pointed out that it's partial because there is no documentation for the spec. I have attempted to seek clarifications on the spec myself both on the namecoin forum and their IRC channels only to be told that only one person really knows how it works and they are hardly ever online. The few answers I was able to get simply confirmed that source code can be relied upon as a guide only, there are details of the spec that are ambiguous in the reference implementation and cannot be definatively determined using it as the only reference.
So the bottom line is that every pool that wants to adopt merged mining currently has no choice but the use the untested merged-mining-proxy black box. So the MM spec is not documented and frankly I think it's grossly irresponsible of the people pushing MM to have let it get this far without doing so well in advance of the cutover block. Without hours/days of poring over the code (in 2 different languages) it's essentially a black box. The provided solution creates a number of problems and the sensible thing to do would be for pools to simply refuse to touch it until that situation is addressed.
Unfortunately merged mining has created a situation where adopting the change is very difficult to resist. Once one pool adopts it, it puts enormous pressure on the others to follow as the miners will flock to the pool that offers free extra Xcoins for the same mining effort. End result is we have a mass of pools struggling to cope with new xcoind patches and an unproven python point of potential failure/bottleneck and no one available to support it except the merged mining developers who seem to be online for about 10 mins/week.
At best the provided tools (merged-mining-proxy) should be considered a reference implementation of a spec that doesn't exist. I predict there will be grief for pools and miners over the next few weeks/months. The best case outcome I can think of is that the extra NMCs mined tank the namecoin market and miners lose interest.
If there are problems and 1/2 pools roll back it still doesn't create any incentive for the MM crowd to step up and do the job properly because their motive is increase hash power on the NMC network and they will have acheived that whatever the consequences to bitcoin mining might be...
IMHO merged mining should be stopped until this situation is properly addressed.
