Hacker News Reader

Comment by hodl | Hacker News Reader

You could with an oracle. Without an oracle I think this would be impossible. How will the chain know the key in 10 years but not Bob now?

View on HN

Time-locks: https://www.gwern.net/Self-decrypting-files You can implement them trapdoor/proof-of-work style using squaring or hashing with a reward that can be claimed only by publicly revealing the secret. Eventually you will be able to use witness encryption so you can encrypt a secret to the property 'Bitcoin blockchain has reached 500 additional blocks' which can only be decrypted by providing the valid PoW-hashes of 500 blocks etc.

> Eventually you will be able to use witness encryption so you can encrypt a secret to the property 'Bitcoin blockchain has reached 500 additional blocks' which can only be decrypted by providing the valid PoW-hashes of 500 blocks etc.

How do you prevent abusing that by running it in a simulation in which the difficulty crashes?

The difficulty resets only every ~2 weeks of blocks, so tanking the difficulty still requires the investment of a vast amount of hash power in order to create a parallel chain.

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.

Would this still be possible if the consensus algorithm was changed to proof of stake?

I'm not sure. Maybe you could change the condition to 'n successive stake signatures' but you would also have to model the stake-selection procedure in it... A property over a hash is fairly simple, but rerunning the whole PoS, essentially, is probably going to blow the witness encryption out into astronomical sizes unless someone can think of clever tricks?

What's the point of using the network then?

Why not do everything more efficiently via the "oracle" server?

Yes, exactly -- how does having some sort of external intervention into the protocol make the protocol more robust?

You misunderstand.

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.

By minimizing the role of the oracle, instead of relying on one entity, you can rely on the market. Anybody could be the oracle, they'd put their reputation/offer/price on sale and the stakeholders would select one as they wish.

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.

This is the question that applies to about 99% of Dapps (at least the one that don't simply exist to serve other Dapps) so far.

Reply on news.ycombinator.com