Emulating OP_BLOCKHEIGHT using OP_OUTPOINTTXHASH (or SegWit). American style contracts may be possible.

It should be possible to emulate OP_BLOCKHEIGHT using OP_OUTPOINTTXHASH. A price Oracle could sign the price of an asset (e.g. gold), along with the block-height & (shortened) TXID of the Contract. The initial prices can be encoded in the Contract itself. If a new block is found & the price changes by more than 0.005%, the Oracle broadcasts a change in the Contract's TXID, ideally without changing its P2SH address. The Oracle signs nothing if they can't broadcast a change in TXID, or else an old price could be used later on. This way we may not need an OpCode for block-height.

Shortening the TXID to 20B could reduce data-usage (32B shouldn't be necessary). OP_SPLIT seems sufficient (first or last 20B of TXID), but OP_SHA1 is 2 Bytes less. Instead of repeating it 5 times to verify 5of8 data-sig-messages, it can be OP_DUP'd in Script.

SegWit could work in a similar way. Both counterparties predict like a hundred (or thousand) changes in the Contract's TXID, at various sat/B. SegWit can enforce a covenant by brute forcing every possibility. Then the Oracle can change the TXID predictably. There'd also be a 5-week (or 8-week) timeout-clawback which is pre-signed 2of2, following any chain of TXID changes. It's conceivable to use SegWit for Hedging, instead of OP_CTV (OP_CHECKTEMPLATEVERIFY). Instead of just signing the asset price, the Oracle (e.g. mining pool) could form part of a 2of3 (or 5of8) escrow service, based on OP_RETURN Hedge contracts (e.g. 10x Hedge to gold, paying 2%/month on 10*Principal, with 0.1%&0.1% Open&Close fees). Arguably the OP_RETURN scheme could be best, since the monthly interest rates could be lowest for BTC-Hedging, to the point where txn fees could rise dramatically if it's popular. A Coin which is a Store-of-Value ought to have the best rates. Mining pools could compete on offering Smart-Oracle escrow services if miners demand OP_RETURN smart contracts, to cater to Hedge Funds.

The & in MofN MultiSig can be blinded & kept secret if both counterparties cooperatively Exit. I doubt TapRoot would help.

u/bitcoincashautist mentioned there could be a clock covenant, over at BitcoinCashResearch. However the approach I'm describing doesn't necessarily involve OP_CLTV (except for a 5-week clawback).

One issue with the emulation concept is it could conceivably be "aiding & abetting money laundering" if a well-known Smart-Oracle uses their only PubKey to repeatedly sign the price of gold along with North-Korean TXIDs. One idea is to sign a separate (clock-like) dummy Contract TXID, which may be invoked using OP_UTXOBYTECODE. If all contracts use dummies, it might simplify the Scripts. OP_BLOCKHEIGHT looks simpler & cleaner, where the Oracle can just publicly sign a price every 10 minutes without bothering with any TXIDs or covenants. However invoking OP_BLOCKHEIGHT can't be dsproof protected (many confirmations may be required for all subsequent payments in a chain).

Oracles might use 5 minute moving averages, since on-chain Hedging could cause price manipulation at Centralized Exchanges, but not necessarily for 5 whole minutes.

American-style & European-style Hedging is different because with the latter the Hedge can't Exit before maturity (set maturity only). If Hedges need to be able to Exit whenever they want, the Oracles can sign prices along with TXIDs which change as the block-height changes. It'd cost less to Exit sooner, since the effective premium should go up with block-height.

One potential issue with using 5of8 price feeds is that the Hedge could Exit using 5 prices which are slightly in their favor, conceivably at 100x leverage. 10x leverage is safer than 1x, since only 10% as much money need be risked (similar to a 10% stop-loss).

A P2SH Script for a 5of8 escrow could look like:

2of2 (Cooperative Exit) 1of2+5of8 (Smart-Oracles judge dispute) 2of2+1of8+Return (Smart-Oracle changes TXID of contract) Timeout (5 week clawback) 

The Hedge might always pay the txn fees of TXID changes. The Oracles involved could form part of a Smart-Validator-Network. Like how smartBCH has validators, the OP_RETURN contracts in BTC could have validators, too.