One problem with using the existing block chain is that it ties up BTC in escrow. Suppose we want to wager 1 BTC on bitcoin difficulty 1 year in the future. To do this, we would need to hold 1 BTC in escrow for the next year. If on the other hand we loaned out the BTC at a hypothetical risk-free interest rate of 1%, we could earn around 0.01 BTC in interest during this year. Thus, there is something like a 1% annual tax on speculative transactions that use regular bitcoin.
On the other hand, if we a mine a bond that matures in one year, we don't need to forgo any interest to place bets on difficulty when it matures.
One possibility would be to have miners able to generate lots of coin fractions as long as all future states are only counted once and then allow those "coins" to be traded.
With a secondary chain, transaction fees could be added as part of the system to create an incentive for miners to mine the chain.
There could be a field in the header that matches a block in the main chain. This would allow the 2 chains to be kept in sync.
The script could be used to do some kind of verification, but I am not sure how well it could be hardened.
You could make it so that to unlock the coin (in the main chain), you need a sequence of hashes.
Hash(.....Hash(Hash(<some-value>,Hash(<some-value,HASH(<my-address> | bond hash))) is less than <difficulty target>
The script could be setup so that it pays out if that condition is met.
The more hashes, the longer before claims are paid out after maturity, but the harder it is to brute force the system. Also, if you require all sub-hashes to meet difficulty then it gets even harder to crack (which is what the main chain does). This hardens the p2p security and can again be done with script.
Hash(<some-value,HASH(<my-address | bond hash>) < difficulty
Hash(<some-value>,Hash(<some-value,HASH(<my-address | bond hash>)) < difficulty
However, this should not be done for the first few hashes in the unlock code. This would allow Merkle chains to be formed.
You would submit <my-address | bond hash> to the alternative chain (assuming you were the winner) and it would calculate the unlock code (after a while), while also calculating everyone else's code at the same time. The <some-values> would be other people's claims.
The miners on the alternative chain should refuse to incorporate invalid <my-address | bond hash> pairs. At with the main chain, everyone is sharing the processing power of the network.
One disadvantage is that <difficulty target> would need to be selected in advance, when creating the contract, since it has to be hard coded into the unlock script in for the linked transaction in the main chain. This means that care needs to be taken before adjusting difficulty downwards, since that will mean that chain fails to unlock some of the transactions.
However, if the main chain is anything to go by, a rule that prohibits downward difficulty adjustments shouldn't be an issue.