Erik Aronesty [ARCHIVE] on Nostr: 📅 Original date posted:2021-05-17 📝 Original message:Verifiable Delay Functions ...
📅 Original date posted:2021-05-17
📝 Original message: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 <jlrubin at 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?
>
📝 Original message: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 <jlrubin at 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?
>