{"type":"rich","version":"1.0","title":"Zac Greenwood [ARCHIVE] wrote","author_name":"Zac Greenwood [ARCHIVE] (npub1gy…dvff7)","author_url":"https://yabu.me/npub1gymmksd9tgwzc5w33umlx08sc2ggys3v2cucmpvl7yy9720wh49s8dvff7","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2021-05-18\n📝 Original message:VDFs might enable more constant block times, for instance by having a\ntwo-step PoW:\n\n1. Use a VDF that takes say 9 minutes to resolve (VDF being subject to\ndifficulty adjustments similar to the as-is). As per the property of VDFs,\nminers are able show proof of work.\n\n2. Use current PoW mechanism with lower difficulty so finding a block takes\n1 minute on average, again subject to as-is difficulty adjustments.\n\nAs a result, variation in block times will be greatly reduced.\n\nZac\n\n\nOn Tue, 18 May 2021 at 09:07, ZmnSCPxj via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Good morning Erik,\n\u003e\n\u003e \u003e Verifiable Delay Functions involve active participation of a single\n\u003e \u003e verifier. Without this a VDF decays into a proof-of-work (multiple\n\u003e \u003e verifiers === parallelism).\n\u003e \u003e\n\u003e \u003e The verifier, in this case is \"the bitcoin network\" taken as a whole.\n\u003e \u003e I think it is reasonable to consider that some difficult-to-game\n\u003e \u003e property of the last N blocks (like the hash of the last 100\n\u003e \u003e block-id's or whatever), could be the verification input.\n\u003e \u003e\n\u003e \u003e The VDF gets calculated by every eligible proof-of-burn miner, and\n\u003e \u003e then this is used to prevent a timing issue.\n\u003e \u003e\n\u003e \u003e Seems reasonable to me, but I haven't looked too far into the\n\u003e \u003e requirements of VDF's\n\u003e \u003e\n\u003e \u003e nice summary for anyone who is interested:\n\u003e \u003e https://medium.com/@djrtwo/vdfs-are-not-proof-of-work-91ba3bec2bf4\n\u003e \u003e\n\u003e \u003e While VDF's almost always lead to a \"cpu-speed monopoly\", this would\n\u003e \u003e only be helpful for block latency in a proof-of-burn chain. Block\n\u003e \u003e height would be calculated by eligible-miner-burned-coins, so the\n\u003e \u003e monopoly could be easily avoided.\n\u003e\n\u003e Interesting link.\n\u003e\n\u003e However, I would like to point out that the *real* reason that PoW\n\u003e consumes lots of power is ***NOT***:\n\u003e\n\u003e * Proof-of-work is parallelizable, so it allows miners consume more energy\n\u003e (by buying more grinders) in order to get more blocks than their\n\u003e competitors.\n\u003e\n\u003e The *real* reason is:\n\u003e\n\u003e * Proof-of-work allows miners to consume more energy in order to get more\n\u003e blocks than their competitors.\n\u003e\n\u003e VDFs attempt to sidestep that by removing parallelism.\n\u003e However, there are ways to increase *sequential* speed, such as:\n\u003e\n\u003e * Overclocking.\n\u003e   * This shortens lifetime, so you can spend more energy (on building new\n\u003e miners) in order to get more blocks than your competitors.\n\u003e * Lower temperatures.\n\u003e   * This requires refrigeration/cooling, so you can spend more energy (on\n\u003e the refrigeration process) in order to get more blocks than your\n\u003e competitors.\n\u003e\n\u003e I am certain people with gaming rigs can point out more ways to improve\n\u003e sequential speed, as necessary to get more frames per second.\n\u003e\n\u003e Given the above, I think VDFs will still fail at their intended task.\n\u003e Speed, yo.\n\u003e\n\u003e Thus, VDFs do not serve as a sufficient deterrent away from\n\u003e ever-increasing energy consumption --- it just moves the energy consumption\n\u003e increase away from the obvious (parallelism) to the\n\u003e obscure-if-you-have-no-gamer-buds.\n\u003e\n\u003e You humans just need to get up to Kardashev 1.0, stat.\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210518/2f1a992a/attachment.html\u003e"}