Hacker News Reader

Comment by gwern | Hacker News Reader

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.

View on HN

> 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?

Reply on news.ycombinator.com