I think we could give the miner a transaction fee that is only valid if the rest of the nodes running the new protocol accept the hash in the block. That would give the miner a good incentive to get the exchange rates right.

So now every client needs to validate every single block just to be able to ensure that transaction that occurred sometime after that block does not rely on something that is invalidated?

Now you're back into the 'validating transactions is so impractical as to be impossible' scenario.

I definitely don't want to compete with bitcoin hashing in any way. I just want to give miners an incentive to include an extra hash in the blocks they are already generating.

Our blockchain will in no way need to be verified by bitcoin, except when bitcoin enters or leaves.  That can happen much less frequently and carry a much larger transaction fee as incentive.

I am not sure about that.  Even validating simple bitcoin transactions requires knowing the entire history of the transaction chain that leads up to the transaction in question.  Except that because bitcoin only allows validated transactions into the block chain, and because each transaction completely spends the output of the prior transaction, you really only need to keep track of the most recent transaction in every chain of transactions.

In your proposal it seems that, since the bitcoin miners aren't doing any work at all to validate your data set before including the block, every client is going to have to evaluate every single data set completely in order to have an accurate picture of what transactions going forward from that point are valid and which ones aren't.  It just seems like an incredible multiplication of the amount of work for everyone.

With bitcoin, a client can keep just the block chain headers and from that, it can query to someone with more resources than itself to validate transactions in a light weight manner, and can verify their results based on the small block chain headers that it stores (~4 MB per year, easily sustainable for every bitcoin peer).  How will such a thing be done in your external block chain, which will have both valid and invalid blocks and for which the client will not know, just from bitcoin block headers, which ones were valid and which ones weren't?

I don't see how you think this can work.  Why would anyone vote for the correct exchange rate?  Any rational person would vote for the option that pays out the escrow funds to their side of the bet.

I was referring to it in the limited capacity in which I understood it, and in my understanding it introduced transaction chains that require extra work to validate.  But the comments I made in the specific topic never were addressed so I don't know if I was off the mark.

Again, the external exchange rate voting does not affect what the escrow funds pay out to whom (that is decided by supply and demand). The external exchange rate ONLY affects the fees on transactions, nudging them towards the external exchange rate.

Also, keep in mind that the only real mechanism for "voting" is to reject a block because it doesn't match the exchange rate you calculated. The vast, vast majority of clients have a strong incentive to get it right. It would take massive collusion to get more than 50% of the computing power to accept a different external exchange rate, and that would only accomplish an annoying change in the fee structure. There are a lot more lucrative things you could do with 51% of bitcoin hashing power.

I am totally confident that the distributed exchange rate would work just fine if implemented correctly. The main disruptive idea here is the transfer of volatility risk from the token holders to the hyperbitcoin holders. That is the scary new thing to me, and while it seems like it would work to me, it is not clear what the exact rules should be, or how it could be tested.

What, no link?!

Sigh. OK, I'll search for it. Here it is: https://bt.irlbtc.com/view/19130.0