Testnet Merged Mining Block Number

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

Re: Testnet Merged Mining Block Number

Post by vinced » Thu Aug 25, 2011 2:01 am

cosurgi wrote: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.
I agree. I don't really see any showstoppers. I suggest we move forward. See:

https://dot-bit.org/forum/viewtopic.php?p=1716#p1716
!v | Namecoin founder | https://dot-bit.org/

Luke-Jr
Posts: 13
Joined: Wed Aug 10, 2011 3:33 am
os: linux

Re: Testnet Merged Mining Block Number

Post by Luke-Jr » Mon Aug 29, 2011 6:11 am

Is it possible to submit blocks that match the namecoin difficulty, but NOT the bitcoin difficulty?

Delia
Posts: 9
Joined: Fri Aug 12, 2011 8:32 pm
os: linux

Re: Testnet Merged Mining Block Number

Post by Delia » Mon Aug 29, 2011 6:30 am

Yes. Such blocks will be accepted by the namecoin chain and rejected by the bitcoin chain.

johntobey253
Posts: 17
Joined: Mon Jun 13, 2011 3:58 am
os: linux

Re: Testnet Merged Mining Block Number

Post by johntobey253 » Tue Sep 13, 2011 3:01 am

vinced wrote:
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.
There is a more flexible solution to the problem.

The problem is that, with MM as first implemented, a miner could cheat the proof-of-work system by putting more than one Namecoin block header into one Bitcoin block. This "cheating" would not cause a problem if the Namecoin blocks all had the same previous-block hash: one or another would win the race, as happens when competing blocks enter the network. The problem would arise if a linked series of Namecoin blocks all existed in one Bitcoin block's aux Merkle trees. The miner could work on them all at once, getting more from his hashes than difficulty warrants.

Vince's solution is to constrain the paths by which Namecoin blocks may be embedded in Bitcoin blocks. This works, but it complicates the picture for miners and chain designers in a future with many merged-mining chains.

A better solution for new chains is to prevent the existence of linked series of aux chain blocks which lack proof of work. You might do that by requiring each aux chain block to refer (perhaps via its own coinbase or a new header field) to the "solution" (target-meeting hash of parent chain block) as well as the hash of the previous block in the aux chain. In Bitcoin, these two are the same, namely hashPrevBlock. Force blocks to refer not just to the previous block in the chain but to the proof of work on that block. A series of aux blocks all being worked on would not make sense, because the second block in the series would have to reference the first block's solution, so the first block would have to have been solved.

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

Re: Testnet Merged Mining Block Number

Post by vinced » Wed Sep 14, 2011 2:11 am

johntobey253 wrote: ...
A better solution for new chains is to prevent the existence of linked series of aux chain blocks which lack proof of work. You might do that by requiring each aux chain block to refer (perhaps via its own coinbase or a new header field) to the "solution" (target-meeting hash of parent chain block) as well as the hash of the previous block in the aux chain. In Bitcoin, these two are the same, namely hashPrevBlock. Force blocks to refer not just to the previous block in the chain but to the proof of work on that block. A series of aux blocks all being worked on would not make sense, because the second block in the series would have to reference the first block's solution, so the first block would have to have been solved.
I agree, this is a cleaner solution. I think my solution is still good enough because you can increase the size of the merkle tree cheaply so collisions can be avoided.
!v | Namecoin founder | https://dot-bit.org/

johntobey253
Posts: 17
Joined: Mon Jun 13, 2011 3:58 am
os: linux

Re: Testnet Merged Mining Block Number

Post by johntobey253 » Wed Sep 14, 2011 6:40 pm

vinced wrote:I agree, this is a cleaner solution. I think my solution is still good enough because you can increase the size of the merkle tree cheaply so collisions can be avoided.
Yes, and thank you very much for implementing it.

Post Reply