From: Michael Dubrovsky <mike@powx.org>
To: Erik Aronesty <erik@q32.com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Cc: SatoshiSingh <SatoshiSingh@protonmail.com>
Subject: Re: [bitcoin-dev] Opinion on proof of stake in future
Date: Wed, 19 May 2021 11:30:36 -0400 [thread overview]
Message-ID: <CAKy8i-0efmC_AmAK6oLy1FooXd6WeSeOvRUOJ8Lb6BJoqduDTQ@mail.gmail.com> (raw)
In-Reply-To: <CAKy8i-17Snk7ZeTL_U8ULDm3S5fYRXf412p1NpS_6CTT4Fhm0A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4115 bytes --]
Ah sorry, I didn't realize this was, in fact, a different thread! :)
On Wed, May 19, 2021 at 10:07 AM Michael Dubrovsky <mike@powx.org> wrote:
> Folks, I suggest we keep the discussion to PoW, oPoW, and the BIP itself.
> PoS, VDFs, and so on are interesting but I guess there are other threads
> going on these topics already where they would be relevant.
>
> Also, it's important to distinguish between oPoW and these other
> "alternatives" to Hashcash. oPoW is a true Proof of Work that doesn't alter
> the core game theory or security assumptions of Hashcash and actually
> contains SHA (can be SHA3, SHA256, etc hash is interchangeable).
>
> Cheers,
> Mike
>
> On Tue, May 18, 2021 at 4:55 PM Erik Aronesty via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> 1. i never suggested vdf's to replace pow.
>>
>> 2. my suggestion was specifically *in the context of* a working
>> proof-of-burn protocol
>>
>> - vdfs used only for timing (not block height)
>> - blind-burned coins of a specific age used to replace proof of work
>> - the required "work" per block would simply be a competition to
>> acquire rewards, and so miners would have to burn coins, well in
>> advance, and hope that their burned coins got rewarded in some far
>> future
>> - the point of burned coins is to mimic, in every meaningful way, the
>> value gained from proof of work... without some of the security
>> drawbacks
>> - the miner risks losing all of his burned coins (like all miners risk
>> losing their work in each block)
>> - new burns can't be used
>> - old burns age out (like ASICs do)
>> - other requirements on burns might be needed to properly mirror the
>> properties of PoW and the incentives Bitcoin uses to mine honestly.
>>
>> 3. i do believe it is *possible* that a "burned coin + vdf system"
>> might be more secure in the long run, and that if the entire space
>> agreed that such an endeavor was worthwhile, a test net could be spun
>> up, and a hard-fork could be initiated.
>>
>> 4. i would never suggest such a thing unless i believed it was
>> possible that consensus was possible. so no, this is not an "alt
>> coin"
>>
>> On Tue, May 18, 2021 at 10:02 AM Zac Greenwood <zachgrw@gmail.com> wrote:
>> >
>> > Hi ZmnSCPxj,
>> >
>> > Please note that I am not suggesting VDFs as a means to save energy,
>> but solely as a means to make the time between blocks more constant.
>> >
>> > Zac
>> >
>> >
>> > On Tue, 18 May 2021 at 12:42, ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
>> >>
>> >> Good morning Zac,
>> >>
>> >> > VDFs might enable more constant block times, for instance by having
>> a two-step PoW:
>> >> >
>> >> > 1. Use a VDF that takes say 9 minutes to resolve (VDF being subject
>> to difficulty adjustments similar to the as-is). As per the property of
>> VDFs, miners are able show proof of work.
>> >> >
>> >> > 2. Use current PoW mechanism with lower difficulty so finding a
>> block takes 1 minute on average, again subject to as-is difficulty
>> adjustments.
>> >> >
>> >> > As a result, variation in block times will be greatly reduced.
>> >>
>> >> As I understand it, another weakness of VDFs is that they are not
>> inherently progress-free (their sequential nature prevents that; they are
>> inherently progress-requiring).
>> >>
>> >> Thus, a miner which focuses on improving the amount of energy that it
>> can pump into the VDF circuitry (by overclocking and freezing the
>> circuitry), could potentially get into a winner-takes-all situation,
>> possibly leading to even *worse* competition and even *more* energy
>> consumption.
>> >> After all, if you can start mining 0.1s faster than the competition,
>> that is a 0.1s advantage where *only you* can mine *in the entire world*.
>> >>
>> >> Regards,
>> >> ZmnSCPxj
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
> --
> Michael Dubrovsky
> Founder; PoWx
> www.PoWx.org <http://www.powx.org/>
>
--
Michael Dubrovsky
Founder; PoWx
www.PoWx.org <http://www.powx.org/>
[-- Attachment #2: Type: text/html, Size: 5905 bytes --]
next prev parent reply other threads:[~2021-05-19 15:30 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-07 17:17 [bitcoin-dev] Opinion on proof of stake in future SatoshiSingh
2021-05-07 23:04 ` Eric Voskuil
2021-05-08 14:33 ` Karl
2021-05-09 10:21 ` R E Broadley
2021-05-09 10:59 ` Karl
2021-05-07 23:19 ` Jeremy
2021-05-08 2:40 ` honest69abe
2021-05-08 14:42 ` Karl
2021-05-09 19:07 ` Cloud Strife
2021-05-08 13:44 ` Eric Martindale
2021-05-09 11:30 ` R E Broadley
2021-05-10 14:08 ` Erik Aronesty
2021-05-10 15:01 ` Keagan McClelland
2021-05-10 21:22 ` LORD HIS EXCELLENCY JAMES HRMH
2021-05-10 21:51 ` Jeremy
2021-05-17 16:58 ` Erik Aronesty
2021-05-18 7:06 ` ZmnSCPxj
2021-05-18 10:16 ` Zac Greenwood
2021-05-18 10:42 ` ZmnSCPxj
2021-05-18 14:02 ` Zac Greenwood
2021-05-18 18:52 ` Erik Aronesty
2021-05-19 14:07 ` Michael Dubrovsky
2021-05-19 15:30 ` Michael Dubrovsky [this message]
2021-05-21 0:04 ` Billy Tetrud
2021-05-21 9:42 ` vizeet srivastava
2021-05-21 20:57 ` Erik Aronesty
2021-05-21 21:45 ` Billy Tetrud
2021-05-23 3:41 ` Lloyd Fournier
2021-05-23 19:10 ` Billy Tetrud
2021-05-23 19:28 ` Billy Tetrud
2021-05-24 13:47 ` Erik Aronesty
2021-05-24 20:43 ` Billy Tetrud
2021-05-24 21:49 ` Erik Aronesty
2021-05-25 1:52 ` Billy Tetrud
2021-05-25 13:00 ` Erik Aronesty
2021-05-25 20:01 ` Billy Tetrud
2021-05-25 21:10 ` befreeandopen
2021-05-26 6:53 ` Billy Tetrud
2021-05-26 13:11 ` befreeandopen
2021-05-26 22:07 ` Erik Aronesty
2021-05-28 14:40 ` befreeandopen
2021-05-28 20:06 ` Erik Aronesty
2021-05-28 21:40 ` Billy Tetrud
2021-06-01 8:21 ` befreeandopen
2021-06-01 16:33 ` Erik Aronesty
2021-06-01 19:26 ` befreeandopen
2021-06-01 20:28 ` Erik Aronesty
2021-06-03 5:30 ` SatoshiSingh
2021-06-07 6:15 ` Billy Tetrud
2021-05-27 10:08 ` Billy Tetrud
2021-05-27 13:11 ` Erik Aronesty
2021-05-28 14:36 ` befreeandopen
2021-05-25 8:22 ` befreeandopen
2021-06-15 11:13 ` James MacWhyte
2021-06-17 1:48 ` Lloyd Fournier
2021-06-17 3:31 ` Cloud Strife
2021-06-22 17:45 ` Billy Tetrud
2021-06-23 18:14 ` Keagan McClelland
2021-06-24 0:14 ` Billy Tetrud
2021-06-24 0:37 ` Keagan McClelland
2021-06-24 17:34 ` yanmaani
2021-06-24 21:50 ` Erik Aronesty
2021-06-25 0:29 ` yanmaani
2021-06-25 16:08 ` Ruben Somsen
[not found] ` <MN2PR10MB4030EBD14EF82E29CFEDD00FB1069@MN2PR10MB4030.namprd10.prod.outlook.com>
2021-06-26 16:26 ` Billy Tetrud
2021-05-08 10:21 Prayank
[not found] <mailman.100801.1624522329.32591.bitcoin-dev@lists.linuxfoundation.org>
2021-06-24 8:59 ` Carlo Spiller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAKy8i-0efmC_AmAK6oLy1FooXd6WeSeOvRUOJ8Lb6BJoqduDTQ@mail.gmail.com \
--to=mike@powx.org \
--cc=SatoshiSingh@protonmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=erik@q32.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox