Namecoin Forum

nodemaster wrote:

Luke-Jr wrote:Why is it so hard to simply disallow a master-chain block from "vouching for" more than one block in each aux chain? :/

Mhmm, If I understand it correctly this might be undesirable because it might be (and is common) that you solve several AUX chain blocks and have one master-block vouching for them, right? This problem would only be solved if the difficulty of both blockchains draw levels.

This was solved in the current code by requiring each chain to appear in a specific (pseudo-random) spot in the aux chain merkle tree, based on the chain ID. So for a specific chain ID, you would only be able to "solve" one aux chain block per parent block.

It's good to see you all evaluating the details of the implementation and I appreciate the feedback. The more eyes on this the better.

vinced wrote:

Luke-Jr wrote:...
Problems with this "header" approach:
1) It takes up extra space in the coinbase -- we only have 100 bytes, each merkle takes up 33; that gives us room for 3 aux chains at most. Adding 4 more bytes for a header kills any hope of ever doing 3 aux chains. (in fact, it would be nice if the space requirements were reduced...)
2) Since the code only allows the header once, you can't have two aux chains.
3) The header can occur accidentally in other coinbase data.

Why is it so hard to simply disallow a master-chain block from "vouching for" more than one block in each aux chain? :/

These concerned have already been addressed in the current code. The aux chain merkle root is stored in the parent coinbase. You can have any number of aux chains under that root with no growth in the parent coinbase.

The chance of accidental appearance of the header in coinbase data is too small to worry about - 2^-32.

Merkle roots contain/reference transactions, not aux chains... or am I missing something?

The chance of accidental appearance of the header is not small at all. Just see how long it takes to vanitygen an address with 2 or 3 specific characters.

Luke-Jr wrote:

vinced wrote:The chance of accidental appearance of the header in coinbase data is too small to worry about - 2^-32.

Merkle roots contain/reference transactions, not aux chains... or am I missing something?

The chance of accidental appearance of the header is not small at all. Just see how long it takes to vanitygen an address with 2 or 3 specific characters.

if there was a way of putting a single number at the start of data, and this number would be the offset telling where the header starts - it would solve this problem.

cosurgi wrote:

Luke-Jr wrote:

vinced wrote:The chance of accidental appearance of the header in coinbase data is too small to worry about - 2^-32.

Merkle roots contain/reference transactions, not aux chains... or am I missing something?

The chance of accidental appearance of the header is not small at all. Just see how long it takes to vanitygen an address with 2 or 3 specific characters.

if there was a way of putting a single number at the start of data, and this number would be the offset telling where the header starts - it would solve this problem.

... or the master block chain could simply only be recognized as valid once.

I still seem to have a problem with slow mining using merge mining as it's taken 7 hours to get this 2011-08-14T10:09:41.168619,solve,0,0,1,1,1
I've got many of these 2011-08-14T09:53:57.364787,solve,0,0,0,1,1
the "difficulty" : 0.06198025, one the 2nd aux in this case mm2TEST should not have taken 7 hours
this is with 270kh/sec miner
I see no errors but it just seems very slow to mine
;;bc,calcd 270 0.061 shows it I should get gribble: The average time to generate a block at 270 Khps, given the supplied difficulty of 0.061, is 16 minutes and 10 seconds

I used this in the proxy line:
/home/sacarlson/Downloads/mmproxy --parent-url http://yourusername:yourpassword@127.0.0.1:48332/ --aux-url http://yourusername:yourpassword@127.0.0.1:10332/ http://yourusername:yourpassword@127.0.0.1:12332/ http://yourusername:yourpassword@127.0.0.1:14332/ http://yourusername:yourpassword@127.0.0.1:13332/ --merkle-size 4 -w 9992

This is using MultiCoin-exp that uses your merged code for merge mining with test chain configs, bitcoin.conf.namecoin diff 94035.90217415 as parent, aux1 beerA difficulty 50.0, aux2 mm2TEST diff 0.06198025, aux3 mm4TEST diff 0.01475864, aux4 mm3TEST diff 0.00441692,

anyone else getting slow results with merge mining test or did i configure something wrong or maybe my code problems? I'll try some simpler experments with just a parent and 1 aux to take a closer look at results, some details of how I setup can be seen http://bitcointalk.org/index.php?topic= ... #msg394289 I'm using my latest Multicoin-exp release in github

Update 8/15/11 10:58am BKK:
I ran another merge mine experiment of just parent and one aux with new difficulties parent of .062 and aux chain diff .010
experment ran with 280kh/sec run from 15:07 block2 to 3:25 block 52 = about 14.4minits per block on both parent and aux chain
So the good news is I get about what I would expect on the parent chain ;;bc,calcd 280 0.062
gribble: The average time to generate a block at 280 Khps, given the supplied difficulty of 0.062, is 15 minutes and 51 seconds
The bad news is I don't get as much as I would expect from the aux chain. I just don't have a full understanding why.
;;bc,calcd 280 0.010
gribble: The average time to generate a block at 280 Khps, given the supplied difficulty of 0.010, is 2 minutes and 33 seconds
sample as seen from proxy:
2011-08-14T15:07:12.921571,solve,1,1
2011-08-14T15:08:53.573864,solve,1,1
2011-08-14T15:32:25.379898,solve,1,1
2011-08-14T15:44:39.154894,solve,1,1

sacarlson: I don't know your configuration, but are you aware of the fact, that you are mining on all blockchains with the difficulty of the parent chain, even if the AUX chain has a lower difficulty? This is because your getworks are for the parent chain and only possible solutions (which might fit the parents difficulty) are also compared as a possible solution for each AUX chain.

nodemaster wrote:sacarlson: I don't know your configuration, but are you aware of the fact, that you are mining on all blockchains with the difficulty of the parent chain, even if the AUX chain has a lower difficulty? This is because your getworks are for the parent chain and only possible solutions (which might fit the parents difficulty) are also compared as a possible solution for each AUX chain.

What happens if the aux chain has a higher difficulty than the parent chain?

I've seen reports on irc that 'getdifficulty' on the merged mining blockchain reports an incorrect value. Can anyone confirm this?

getdifficulty reports 0.24236496 for me, which I think is roughly consistent with the mining rate I've been getting (about 3-4 blocks per hour at 700-800 khps, and there doesn't seem to be anyone else mining on namecoin testnet).

Delia wrote: What happens if the aux chain has a higher difficulty than the parent chain?

In this case you'll find many parent chain blocks and very low AUX chain blocks. But the bigger problem would be in NMC/BTC case, that you need all BTC clients to update to get their client merged mining ready as AUX chain support needs a major update