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.