public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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 --]

  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