An interesting approach to solving this is homomorphic encryption. This allows for alice to give Bob to encrypted numbers A and B. Bob can then compute an encrypted version of A + B using only the encrypted versions of A and B. This could be used by putting an encrypted secret on the blockchain, after which everyone can compute using that secret, but cannot see the actual outcome.
This still won't help with random number generation though, because it remains deterministic.
https://medium.com/novamining/mast-smart-contracts-on-bitcoi...
To support our secure key storage work, we'll be bringing a random beacon built on similar core concepts to the Ethereum chain for Keep.
Revealing the key, for dead-man-switch-type operations for example, is also a possibility.
Take your secret key, split it into N pieces, create M parity pieces, RAID-style, for redundancy, distribute to M+N lawyers with instructions to reveal in 10 years. Lawyers put them into safe-deposit boxes for the duration, reveal in 10 years.
A mildly eccentric person could even do this at scale: create a public/private keypair for every year for the next, say, century, publish the public keys, distribute the private key pieces with instructions to a wide range of lawyers. Members of the public can encrypt and publish data with the appropriate public key, assuming they trust the system.
SSS solves a harder problem than (my understanding of) RAID parity: that it requires not just k out of i pieces (your N and M+N) to assemble a secret, but also that no fewer than k pieces is sufficient, for arbitrary 0 < k < i.
These days, SSS is commonly recommended (I don't know whether it's also commonly used) for storing cryptocurrency wallet backups.
[1]: https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing
How do you prevent abusing that by running it in a simulation in which the difficulty crashes?
Secondly, as I understand witness encryption, if you're able to encode the hash rules as the condition, it would be easy to throw in an additional condition like 'all hash difficulties (# of leading zeros) must be >= difficulty XYZ', and simply ban large difficulty reductions. Which works as long as Bitcoin remains popular and justifying high-difficulty blocks, and if it crashes, your timelock is no longer secure so you don't want it to open and to failsafe.
Why not do everything more efficiently via the "oracle" server?
If a smart contract relies on an external data source from a normal server (oracle), then why even take the risk of deploying the smart contract?
If you're using an oracle for a data source you might as well do everything on a normal database.
You're still trusting the selected oracle to behave honestly, but they will be operating in a very competitive market which hopefully would lead to better behaviour. They might cheat once, but it would be trivial to switch to a better oracle next time.
You could later publish a decryption key into the blockchain that the contract uses, but I don't think that's "automatic" in the sense the earlier posts were hoping for.