Topic: Need technical asistance with implementing merge mining (Read 1062 times)

 I can help you if you change your mind. 

If it was a 10 minute fix you wouldn't be here asking for help. No one is responding because you are cheap. I'm done here as well. Good luck.

If I was looking for someone to spend hours implementing this, then I would offer more than $50.  I am looking for someone with a fresh mind and who knows what they are doing to spend ten minutes looking over what I've done to find any flaws in my implementation.  I can program the fix; the problem is finding the bug.

Clearly you don't want it fixed that bad, you're trying to pay $25 and then possibly split it between multiple people, what the fuck? C++ coders don't make less than 6 figures here in the US.

I'm working on enabling merge mining for the Prohashing mining pool. I've spent 45 hours trying to get the dogecoin daemon to accept a merge mined block, with no success. I'm posting my progress in this post, in the hopes that someone who has experience in merge mining can figure out what is wrong.  I'm willing to pay the first person $50 equivalent in in BTC who can tell me what is wrong with what I am doing.  If there are multiple issues, then I'll split the reward amongst all the helpers.

I simplified the procedure by removing the parts of the algorithm that are irrelevant.

Here is the procedure I used:

1.  Get the latest block from the litecoin testnet and store its data in memory.
2.  Call getauxblock against the dogecoin testnet.  Since this example is only going to merge mine dogecoins, we ignore "chainid" and store only "hash" in memory.  "Target" is obtained by calling getblocktemplate, because we need difficulty and other things from the full template for calculating payouts.  "Target" in getauxblock and in getblocktemplate are reversed, so the appropriate conversion is made.
3.  When a block is found for the litecoin testnet, check to see whether the target is less than the dogecoin testnet's target.  If so, we call getauxblock again, passing the "hash" exactly as provided in step 2, without any modification, and the serialized block data as the second parameter.  The help for the command states that the parameters are "getauxblock [hash] [auxpow]."

The result is that the litecoin blocks are always accepted, and the dogecoin blocks are always rejected with the following errors:


Here is an example "auxpow" serialized block that is submitted to the dogecoin damon.  I annotated it as I think is correct, but keep in mind that the annotations could be incorrect and you shouldn't assume that I have identified the correct things to insert or the correct order.  In the real submission, there are no spaces or characters between the separated sections.

Litecoin coinbase transaction:

Double-SHA-256 hash of the litecoin block header:

The length of the merkle branch from the litecoin block, which is the same as the branch sent out in the stratum protocol.  Because this litecoin block has no transactions, the length of the merkle branch is zero:

The litecoin merkle branch, if there were one, would go here in a series of hashes.  Since there are no transactions in the block other than the coinbase transaction, we append nothing here.

The "branch side mask" of the coinbase transaction, which is always zeroes:

The auxiliary branch count, which is zero because we are only mining dogecoins in this example:

The auxiliary branch index, which is also zero because we are only mining dogecoins:

The block header of the litecoin block, in full:


I'll also break down my understanding of what is supposed to be placed in the litecoin coinbase transaction to signify that we are merge mining dogecoins.  Here is my understanding of the litecoin coinbase transaction's merge mining portion, which you can find embedded within the coinbase transaction printed above:

This string signifies that we are merge mining.

The "hash" parameter obtained from the dogecoin daemon's getauxblock command, verbatim:

The following are used for when multiple merge-mined coins are being sought at the same time, but since we are only merge-mining dogecoins, this is a 4-byte 1 followed by a 4-byte 0.


Here are some of the things I tried and the references I used.

1.  https://en.bitcoin.it/wiki/Merged_mining_specification seems to be the primary source on merge mining.  However, I noticed that some of the examples in the document don't work with dogecoins.  For example, the "block hash" in the auxiliary proof of work that is submitted to namecoin in that document (the second field) looks like the proof of work hash for the block, since it ends in a string of zeroes.  Looking at that, I tried placing the scrypt proof of work hash in that field, but it didn't work.

My understanding of the "block hash" is that when you call getblock from a daemon, you provide the double SHA-256 hash of the block header, not the scrypt proof of work hash.  The "block hash" is not the scrypt proof of work hash.

2.  I tried reversing various hashes in the fields of the blocks on the theory that endianness was the problem, but 16 different permutations didn't work.  I tried reversing the dogecoin auxiliary hash, the block hash, the merkle branch hashes (when there are transactions in the litecoin block, which there are not in this example), and even the block header of the litecoin block.  None of these things worked.  I couldn't find a permutation of reversed and non-reversed hashes that made any difference.  Of course, it is possible that, since there are so many permutations, that I missed the correct one and the hashes are not in the correct endianness in the example.

3.  At http://forum.namecoin.info/viewtopic.php?f=7&t=368, there is a poster who offers advice on how to submit merge mined blocks to getauxblock, although that information is specific to namecoin.  I reviewed what I was doing and it appears to be identical to what he is suggesting.

4.  After reviewing the documentation for what a merkle tree is, it took me an entire day to figure out what happens when there are an odd number of transactions in the tree.  It turns out that the algorithm is to hash the nodes with themselves.  Seeing this, I took the example above and I tried specifying the length of the "merkle branch" for the coinbase transaction as "01," and then provided the hash of the coinbase transaction as the only hash in the "merkle branch."  The long-shot idea was that perhaps the dogecoin daemon was looking to hash the coinbase transaction with itself, and use that as the root of the tree.  It still returned the same error.

5.  In the litecoin coinbase transaction, the 44-byte merge mining part (fabe + "mm") is preceded by the length (44, or 2c) in some examples, but not in others.  Apparently, this length is not necessary if the merge mining string is provided within the first 20 characters of the script, so I left it out in this example.  However, in previous iterations, I added an additional byte of "2c" before the merge mining portion and it did not result in any difference in this error.

6.  In these examples, I always assumed that the merkle branches are double-sha256 hashes, even for scrypt coins.  All the documentation I read seems to indicate that in scrypt, the only difference is the algorithm used to verify work.  From what I can tell, the rest of the block still is stored using SHA-256 hashes, as is the hash of the block headers and even the hashes of the transactions.  If there is some difference between scrypt and SHA-256 in how the merge mining headers are stored, that could be a clue.


Thanks to anyone who is willing to try to point out what is wrong here.  We have about 15 features ready for release and merge mining is the only one that is holding back the release.  Your help is greatly appreciated and will be rewarded.