Verifiable Delay Functions involve active participation of a single verifier. Without this a VDF decays into a proof-of-work (multiple verifiers === parallelism).
The verifier, in this case is "the bitcoin network" taken as a whole. I think it is reasonable to consider that some difficult-to-game property of the last N blocks (like the hash of the last 100 block-id's or whatever), could be the verification input. The VDF gets calculated by *every* eligible proof-of-burn miner, and then this is used to prevent a timing issue. Seems reasonable to me, but I haven't looked too far into the requirements of VDF's nice summary for anyone who is interested: https://medium.com/@djrtwo/vdfs-are-not-proof-of-work-91ba3bec2bf4 While VDF's almost always lead to a "cpu-speed monopoly", this would only be helpful for block latency in a proof-of-burn chain. Block height would be calculated by eligible-miner-burned-coins, so the monopoly could be easily avoided. There has been some decent earlier work on blind/uncensorable burns: https://eprint.iacr.org/2019/1096.pdf A miner could then reveal A) the VDF and B) proof-of-burn as a part of a block. Nodes would simply select the block with A) a valid VDF and B) the highest "qualified" POB. With most burns running at a loss, and no way to predict the next "winning burn", and the VDF providing timing, I'm not sure how this is worse than Bitcoin's existing system. On Mon, May 10, 2021 at 5:51 PM Jeremy <jlru...@mit.edu> wrote: > > re: 2, there's been some promising developments with Verifiable Delay > Functions that make me think that the block regulation problems are solvable > without requiring brute-force search proof of work. Are those inapplicable > for some reason? > _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
