Testnet Merged Mining Block Number

[sacarlson]

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).

That sounds about right: ;;bc,calcd 800 0.24236496
(01:42:03 PM) gribble: The average time to generate a block at 800 Khps, given the supplied difficulty of 0.24236496, is 21 minutes and 41 seconds.
So what namecoin commitish are you now running to get these numbers? my experiments had vincent merged code at commit 9ed975bc44c9e5c60e, What config settings might I missed? or maybe I broke something in my merge.

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

You would see this from the mmproxy if parent is less diff then child chain:
ERROR: AUX POW parent hash 0000000964b614867559487da64722a0e4876de8fbc45e3b15bd7e07b2f03625 is not under target 00000007fff80000000000000000000000000000000000000000000000000000
as seen from merge-miner-proxy:

[Delia]

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).

That sounds about right: ;;bc,calcd 800 0.24236496
(01:42:03 PM) gribble: The average time to generate a block at 800 Khps, given the supplied difficulty of 0.24236496, is 21 minutes and 41 seconds.
So what namecoin commitish are you now running to get these numbers? my experiments had vincent merged code at commit 9ed975bc44c9e5c60e, What config settings might I missed? or maybe I broke something in my merge.

vinced, commit 9f82d31952015fe079046a0804bd4cc257c5e0c6. I didn't really do anything config-ish beyond the basic RPC user/pass, setgenerate true 2, change port to not conflict with bitcoind, etc.

[vinced]

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).

That sounds about right: ;;bc,calcd 800 0.24236496
(01:42:03 PM) gribble: The average time to generate a block at 800 Khps, given the supplied difficulty of 0.24236496, is 21 minutes and 41 seconds.
So what namecoin commitish are you now running to get these numbers? my experiments had vincent merged code at commit 9ed975bc44c9e5c60e, What config settings might I missed? or maybe I broke something in my merge.

vinced, commit 9f82d31952015fe079046a0804bd4cc257c5e0c6. I didn't really do anything config-ish beyond the basic RPC user/pass, setgenerate true 2, change port to not conflict with bitcoind, etc.

That looks like the correct difficulty for testnet namecoin. Here's a sample block from before merged mining:

http://testnet.explorer.dot-bit.org/b/13500

Last difficulty transition was at 14112 from 0.265 to 0.242.

[vinced]

...
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?

There is a new merkle tree introduced by the merged mining code. This tree is used to organize the auxiliary chains so that the parent coinbase can be kept small.

See https://en.bitcoin.it/wiki/Alternative_ ... Scaling_up.

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.

All that's going to happen is that 2^-32 of mined blocks are going to be rejected by the aux chains. That's an insignificant reduction in mining efficiency.

[vinced]

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.

The mm-proxy returns the lowest difficulty of the parent and all the auxs to the getwork request. Any block found above that difficulty is submitted to all the chains. Each chain will accept or reject the block based on its own difficulty.

[Delia]

The mm-proxy returns the lowest difficulty of the parent and all the auxs to the getwork request. Any block found above that difficulty is submitted to all the chains. Each chain will accept or reject the block based on its own difficulty.

This seems suboptimal. Wouldn't it be more efficient for the miner to check the difficulty versus each chain personally, and only submit the block to those chains where it qualifies? That way, only one person (the miner) needs to check each failing block, whereas in the current implementation, each peer on each chain needs to check each failing block.

[Luke-Jr]

See https://en.bitcoin.it/wiki/Alternative_ ... Scaling_up.

Ok, having read this page I have a lot more (hopefully constructive) criticism:
1. Bitcoin already has its own serialization format. Protobuf adds yet another dependency, and breaks compatibility regularly.
2. Putting every transaction in MyBlock means including transactions has a per-work overhead if a miner wishes to keep his alternates up to date.
3. BitcoinData has no correlation to any actual Bitcoin message I'm aware of-- certainly not the block header.

[vinced]

See https://en.bitcoin.it/wiki/Alternative_ ... Scaling_up.

Ok, having read this page I have a lot more (hopefully constructive) criticism:
1. Bitcoin already has its own serialization format. Protobuf adds yet another dependency, and breaks compatibility regularly.
2. Putting every transaction in MyBlock means including transactions has a per-work overhead if a miner wishes to keep his alternates up to date.
3. BitcoinData has no correlation to any actual Bitcoin message I'm aware of-- certainly not the block header.

I only offered that page for an explanation of the new merkle tree. My actual implementation is different from what the page describes and follows the "bitcoin way" quite closely. Definitely no protobufs.

The best way to review the design is to read and undestand the code on the mergedmine branch.

[nodemaster]

Are we now stuck here? I've heard and read much criticicm but I'm missing vital suggestions on how to make it better and I'm even not smart enough to figure out why those points are problems at all. I have to confess, that I'm kinda lost. I assume to know the current implementation (please correct me if I'm wrong) and IMHO it works without problems. Do we really have a problem here and is this problem a show stopper? Or on the other hand are we missing information about how this implementation behaves in rare circumstances? I'm willing to test different scenarios on alpha if we need more input. Thus please let me know if I can do anything helpful.

[cosurgi]

I have similar impressions. Are we stuck really? why? If yes, then what to do to get un-stuck?

I think that it works - it was tested - and it should go to production.