Difiicult question related to merged mining

[pent]

The sutuation: classical merged-mining scheme. PARENT and AUX chains.

The problem: I need to send a transaction TRX1 in PARENT chain to some address or hash. And another TRX2 in AUX chain. These transactions are cross-referenced to each other by some marks in Script. Is there any solution the funds of TRX1 to be widthdrawn only by miner who merge-mined AUX block with TRX2?

I don't know who will mine AUX block, but i want to pre-pay a reward for him in PARENT chain.

Thanks.

[1713852386]

1713852386

[1713852386]

1713852386

[dscotese]

I hit this thread because I have what seems like an easy question, but I can't find the answer.  I'll get to that in a moment.

I think the reason no one has replied to this question is that it is difficult to understand.  But I think the answer is easy.  The miner who finds a solution for the AUX block that contains TRX2 will presumably be identified in the AUX chain as the winner, somehow.  If the identifier is a public key that is used to sign the first part of the data of TRX1, then the script required to succeed for TRX1 to be spent can include a requirement that the spender provide the matching private key (meaning he has to be that miner).

In fact, you can write a script into the bitcoin block that requires the spender to have whatever private key you want.

Anyway, my question is about the alleged benefits of merged mining.  Following is my understanding, and my question is: Am I correct, or is there something wrong with my explanation?

The miner's job is to find a nonce for which hashing the concatenation of the block header and that nonce results in a hash below the target.  The block header obviously comes from either the auxiliary chain or the primary chain.  If you're going to try the same nonce for both chains, you have to generate two hashes.  Therefore, so merged mining requires twice as many hashes to try the same number of nonces.  Thus, the only "benefit" of merged mining is in the overhead of setting up mining in the first place.  If you're going to do merged mining, you'll be effectively dividing your hash rate between the various block chains on which you mine.

I don't believe it.  There must be something wrong with my understanding.  Can someone explain what it is?

...or did I pull the curtain back on some folks who thought they could encourage people to waste their mining resources (doubtful!)??

[maaku]

No, you're misunderstanding merged-mining (and btw, if you needed the same nonce to satisfy both proof-of-works, you'd need to do *a lot* more than twice as many hashes).

The hash of the auxiliary block header is included as data somewhere in a transaction of the parent chain. The aux proof of work then is the auxiliary block header for the sub-chain, a bitcoin transaction which contains the auxiliary block header's hash as data somewhere in one of its scripts, a valid bitcoin block header which meets at least the sub-chain's difficulty requirement, and the Merkle path linking the bitcoin transaction to the header. So the only header that ever has to meet a difficulty requirement is the bitcoin header, and the sub-chain aux value doesn't really matter. Make sense?

[dscotese]

The proof of work for the aux chain is:

• the auxiliary block header for the sub-chain
• a bitcoin transaction which contains the auxiliary block header's hash as data somewhere in one of its scripts
• a valid bitcoin block header which meets at least the sub-chain's difficulty requirement
• the Merkle path linking the bitcoin transaction to the header

Items 1, 2, and 4 can be easily computed although obviously item 4 requires item 3.  Is that right?  So the real work is in item three, and if I understand correctly, a particular nonce might yield a hash that meets the sub-chain's target requirement but not the parent chain's (or I suppose the other way around?).  But dot-bit's explanation suggests there are two lotteries, either of which could be won, and the explanation as I understand it means you could win one (whichever has the easier target - would that always be the sub-chain?) or both (meeting the other target meets both targets), but not the harder one by itself (because that would obviously also meet the easier one).

This matters to me because I'm trying to follow the efforts to reduce the storage requirements for those who want to run a full client, and that led me to etothepi's post in which he explained that the "tree signatures" for alt chain that would provide the "unspent-TxOut list" would be secured by merged mining.

I think an important point for me might be that etothepi's thread doesn't propose anything that reduces the full-client storage requirements, but rather allows light clients to use bitcoin without a trusted peer.  Even if that is the case, I'd like a better understanding of merged mining.  And any pointer to threads discussing block-chain compression/pruning would be appreciated.

Thanks!

[maaku]

That is correct.

For any two chains with unequal difficulty, it's possible that the proof-of-work meets the difficulty requirement for neither chain, the chain with lower difficulty, or both simultaneously.

This is because proof of work is transitive, as essentially you're checking if the number represented by hash(block-header) is less than the target number represented by the current difficulty/nBits, and “less-than” comparison of integers is transitive. If hash(block) <= bitcoin-target, and bitcoin-target <= namecoin-target, then it MUST also be true that: hash(block) <= namecoin-target and therefore it meets both chain's requirements. Make sense?

Blockchain pruning is what reduces storage requirements. The UTxO meta-chain proposal merely makes it easier for a fully validating but pruned client to get up to speed without downloading the entire block chain, and without having to trust any specific peer. Rather the hypothetical client places its trust in hashpower securing the meta-chain, which presumably they're doing anyway if they're using bitcoin at all.

(The UTxO proposal also greatly improves the security model of light nodes, but that's a separate issue from your question.)

I don't know what the best place is to get up to speed with blockchain pruning, but “ultraprune” is the name of the recently-merged fork that does all the prep work for pruning. Search on that keyword and you should find stuff.