Merged Mining implementation with getmemorypool [solved]

Post Reply
p2k
Posts: 1
Joined: Tue Nov 22, 2011 3:27 pm
os: mac

Merged Mining implementation with getmemorypool [solved]

Post by p2k »

I'm experimenting with bitcoin's getmemorypool call (v0.5). As you might know, this allows you to create a custom generation transaction and thus insert data into the coinbase without tampering with bitcoin's source code. This could be useful for a pool software or an alternate mm-proxy.

On the whole, it boils down to the following two questions:

1) Now, if I wanted to create a coinbase for merged mining, what RPC call would I have to send to namecoind and what do I have to append to the coinbase script?

EDIT: Solved this one myself.
One has to call "getauxblock" without parameters. This returns a target, hash and chainid. The following assumes only one aux chain (which is namecoin).
Compose a char string of the following bytes and append them to the coinbase script:

Code: Select all

0xfa, 0xbe, 0x6d, 0x6d, hash (32 bytes), 0x00000001 (encode as 32bit little endian), 0x00000000 (32bit)
Following the Bitcoin script guidelines, a length byte has to be placed in front of the char string, which is a constant 4+32+4+4 = 44 or 0x2c.

2) And then, when I manage to solve a namecoin block like this (i.e. finding a bitcoin block hash which is below namecoin's difficulty), what do I have to send back to namecoind?

EDIT: Solved this one too after some more hours,
Again, the "getauxblock" is what you have to call, this time with parameters. The first parameter is the hash you got from step 1, the second one is a so-called aux proof-of-work with the following format:

Code: Select all

coinbase transaction (the one you've created in step 1 encoded as bitcoin would encode it)
bitcoin block hash (32bytes)
branch count (encoded as bitcoin var_int)
merkle branches (32byte hashes)
0x00000000 (32bit branch index, always zero)
0x00 (aux branch count as var_int, always zero here)
0x00000000 (32bit aux branch index, always zero here)
bitcoin block header (80bytes as-is)
Now the "merkle branches" are the tricky part. To better understand what they are, take a look at this ascii art, depicting a bitcoin merkle tree with 8 transactions:

Code: Select all

  0   1 2   3 4   5 6   7
   \ /   \ /   \ /   \ /
    a     b     c     d
     \   /       \   /
       A           B
         \       /
           \   /
             R
Now the "merkle branches" are the nodes 1, b and B in this diagram; 0 being the generation transaction. The aux-pow verification algorithm has to check that the generation transaction indeed is included in the bitcoin block. The tree hashes 1, b and B are the only ones which are required to get from the hash of the generation transaction up to the merkle root of the bitcoin block.

Now theoretically, merged mining could tie more than one aux chain together (though not used in practice right now). If this happens, the aux hashes also get organized in a merkle tree which eventually would fill in the aux branch count + aux branches parts which are left empty here. In our case with only one aux chain, the aux merkle hash equals the namecoin hash.

vinced
Posts: 63
Joined: Wed May 18, 2011 1:16 am

Re: Merged Mining implementation with getmemorypool [solved]

Post by vinced »

Do you have a patch to mm-proxy to use getmemorypool?
!v | Namecoin founder | https://dot-bit.org/

Post Reply