path: root/8b/af7620d5e5c7b8578beac0407048b1d1c94868

Return-Path: <earonesty@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 1F0F7C0001
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 24 May 2021 13:47:37 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 0013E82E2A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 24 May 2021 13:47:36 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 0.499
X-Spam-Level: 
X-Spam-Status: No, score=0.499 tagged_above=-999 required=5
 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001,
 HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=q32-com.20150623.gappssmtp.com
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id An7RAAVgyqH3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 24 May 2021 13:47:35 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com
 [IPv6:2607:f8b0:4864:20::1036])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 55A9D82E71
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 24 May 2021 13:47:35 +0000 (UTC)
Received: by mail-pj1-x1036.google.com with SMTP id
 b15-20020a17090a550fb029015dad75163dso11190058pji.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 24 May 2021 06:47:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=q32-com.20150623.gappssmtp.com; s=20150623;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=4PriP8fS1cWJhDedW0X7/7+9lyGjuWKMD9qIVDMEypU=;
 b=Fq38M6tSwyXuVeoEb9Ytep9Y1WLicJ2w6k7wg9EjKn5OxdKG5Fw1pWRgwcEr0yOpnK
 OvrewHEpuSIM4N8oa0txCYGosVDuT/RXG5dE48HsmTUeCjfwFWZ1FiFxzy65lPkpPsRo
 cvvT2ttgsErZrAkiYvuJejGUkYZJtgEENLAKkInypIn4/GmYGN7d5aqra6MViBVXJXGq
 r54AdTXt8slGnxPItQ7WvWfPHm1I3yJBdtRkjoZ57PmVkphPHuuD1Ulbh5FwNYKHR2vX
 SiZmh63ZwIgVDiAPScLkRDMQ4k6Ztn9g5dCe+S2EAElLrXpxp99dD7/IGtmgmmqYhYtk
 P/YQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc:content-transfer-encoding;
 bh=4PriP8fS1cWJhDedW0X7/7+9lyGjuWKMD9qIVDMEypU=;
 b=ZNyiaE42lPXSdxF0+lVSfL0fYkwPhjP4nVc4HSbpTnhWmWE0sTEVgQMmoAOclDznUE
 WLu+zFu2JCgIVJyQGL93PSSERgZlyxQvaCYKLUUFvSk6zI8qa5FrzsyRN8GmWI5ga7BB
 0ilBgau3StPcOmdv5l6lxb9gdtv5NfzhvpIZe7jsPJOzC9+FNVS/vuE4zbIo7EtKSIE5
 ikFwMRsCQ4F9pBFnxmD97fCR+WObusee5YJHSYMl+6c0RYZ4w2C6g2R415XL1ABNhbKt
 tKzJVJTYHb9vTpn/JOlJYKnHgCiG1vJ3qyKN5ApZyGG52gvHAVbuWDXOyEAkG1wOQlIp
 8/2Q==
X-Gm-Message-State: AOAM530ZTByU3ST/jIJ/wlNtHpnsZZCtRIC9059kanTtMCH91o4qvl5X
 a/6bdW+uo+r8CNz+1oHD9LWHJgA899TUph8oa8ThzU0=
X-Google-Smtp-Source: ABdhPJwYQfkzOG88XWTXID4B1Aaw/VZRiu8nTTx568oVFEsDOBFahy2rK6/DW5BA6dQS+0PySlr5db+0c+ZoII4mMzg=
X-Received: by 2002:a17:90a:7141:: with SMTP id
 g1mr5463060pjs.167.1621864054314; 
 Mon, 24 May 2021 06:47:34 -0700 (PDT)
MIME-Version: 1.0
References: <6do5xN2g5LPnFeM55iJ-4C4MyXOu_KeXxy68Xt4dJQMhi3LJ8ZrLICmEUlh8JGfDmsDG12m1JDAh0e0huwK_MlyKpdfn22ru3zsm7lYLfBo=@protonmail.com>
 <CAJowKg+QM94g+JcC-E-NGD4J9-nXHWt5kBw14bXTAWaqZz=bYw@mail.gmail.com>
 <CALeFGL02d9NVp+yobrtc2g6k2nBjBj0Qb==3Ukkbi8C_zb5qMg@mail.gmail.com>
 <CAD5xwhi1G3Jj3FAAWQP3BXTK34ugDQY32hq-cQnt8Ny8JP4eGQ@mail.gmail.com>
 <CAJowKgJ1x5YKWS1S-sgdU3Tn+hPT64iiUCwG8qh-JS0xqS7ieA@mail.gmail.com>
 <30li5MRxkBhzLxLmzRnHkCdn8n3Feqegi-FLZ5VDyIX2uRJfq4kVtrsLxw6dUtsM1atYV25IfIfDaQp4s2Dn2vc8LvYkhbAsn0v_Fwjerpw=@protonmail.com>
 <CAJ4-pEBYJNuNMUCt5J5DbKU4RC9JXcO7gZdKh2Vq6PHCmddaeg@mail.gmail.com>
 <hASF-iYeGlsq3EhNWY0EWhk5S8R1Wwn534cWsrwLInd8K7f7bUDCAP4GgTj8_ZNsKtgv8y09GJovcS6KXhYRHODC5N_88fvCAF1Z-r2TUFg=@protonmail.com>
 <CAJ4-pECb9QSUDPax8SU+-KGwPgVju=YKax9eb-iRwAmZGcMcPg@mail.gmail.com>
 <CAJowKgJ3DOrtO+_XzoEnqQUQdge=zCopg2mvuy5F=RSeaVPJYQ@mail.gmail.com>
 <CAKy8i-17Snk7ZeTL_U8ULDm3S5fYRXf412p1NpS_6CTT4Fhm0A@mail.gmail.com>
 <CAKy8i-0efmC_AmAK6oLy1FooXd6WeSeOvRUOJ8Lb6BJoqduDTQ@mail.gmail.com>
 <CAGpPWDaiGdgrECZzvM67O6t-kVieL4uR4ydEkHr+gwUB7Ahykg@mail.gmail.com>
 <CAH5Bsr2WaOhSObNX-=61md6tF49auaH7wUB08qKv5baiFutxSw@mail.gmail.com>
In-Reply-To: <CAH5Bsr2WaOhSObNX-=61md6tF49auaH7wUB08qKv5baiFutxSw@mail.gmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Mon, 24 May 2021 09:47:24 -0400
Message-ID: <CAJowKgJOZwb0PgW93Y+Jy+yi1kv09Gu7-gjWvt7eUqWfJ_zJuw@mail.gmail.com>
To: Lloyd Fournier <lloyd.fourn@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Mon, 24 May 2021 13:58:54 +0000
Cc: SatoshiSingh <SatoshiSingh@protonmail.com>,
 Billy Tetrud <billy.tetrud@gmail.com>
Subject: Re: [bitcoin-dev] Opinion on proof of stake in future
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 24 May 2021 13:47:37 -0000

> I don't see a way to get around the conflicting requirement that the keys=
 for large amounts of coins should be kept offline but those are exactly th=
e coins we need online to make the scheme secure.

proof of burn clearly solves this, since nothing is held online

>  how does proof of burn solve the "nothing at stake" problem in your view=
?

definition of nothing at stake: in the event of a fork, whether the
fork is accidental or a malicious, the optimal strategy for any miner
is to mine on every chain, so that the miner gets their reward no
matter which fork wins.   indeed in proof-of-stake, the proofs are
published on the very chains mines, so the incentive is magnified.

in proof-of-burn, your burn investment is always "at stake", any
redaction can result in a loss-of-burn, because burns can be tied,
precisely, to block-heights

as a result, miners no longer have an incentive to mine all chains

in this way proof of burn can be more secure than proof-of-stake, and
even more secure than proof of work







>

On Sun, May 23, 2021 at 3:52 AM Lloyd Fournier via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Hi Billy,
>
> I was going to write a post which started by dismissing many of the weak =
arguments that are made against PoS made in this thread and elsewhere.
> Although I don't agree with all your points you have done a decent job he=
re so I'll focus on the second part: why I think Proof-of-Stake is inapprop=
riate for a Bitcoin-like system.
>
> Proof of stake is not fit for purpose for a global settlement layer in a =
pure digital asset (i.e. "digital gold") which is what Bitcoin is trying to=
 be.
> PoS necessarily gives responsibilities to the holders of coins that they =
do not want and cannot handle.
> In Bitcoin, large unsophisticated coin holders can put their coins in col=
d storage without a second thought given to the health of the underlying le=
dger.
> As much as hardcore Bitcoiners try to convince them to run their own node=
, most don't, and that's perfectly acceptable.
> At no point do their personal decisions affect the underlying consensus -=
- it only affects their personal security assurance (not that of the system=
 itself).
> In PoS systems this clean separation of responsibilities does not exist.
>
> I think that the more rigorously studied PoS protocols will work fine wit=
hin the security claims made in their papers.
> People who believe that these protocols are destined for catastrophic con=
sensus failure are certainly in for a surprise.
> But the devil is in the detail.
> Let's look at what the implications of using the leading proof of stake p=
rotocols would have on Bitcoin:
>
> ### Proof of SquareSpace (Cardano, Polkdadot)
>
> Cardano is a UTXO based PoS coin based on Ouroboros Praos[3] with an inbu=
ilt on-chain delegation system[5].
> In these protocols, coin holders who do not want to run their node with t=
heir hot keys in it delegate it to a "Stake Pool".
> I call the resulting system Proof-of-SquareSpace since most will choose a=
 pool by looking around for one with a nice website and offering the larges=
t share of the block reward.
> On the surface this might sound no different than someone with an mining =
rig shopping around for a good mining pool but there are crucial difference=
s:
>
> 1. The person making the decision is forced into it just because they own=
 the currency -- someone with a mining rig has purchased it with the intent=
 to make profit by participating in consensus.
>
> 2. When you join a mining pool your systems are very much still online. Y=
ou are just partaking in a pool to reduce your profit variance. You still s=
ee every block that you help create and *you never help create a block with=
out seeing it first*.
>
> 3. If by SquareSpace sybil attack you gain a dishonest majority and start=
 censoring transactions how are the users meant to redelegate their stake t=
o honest pools?
> I guess they can just send a transaction delegating to another pool...oh =
wait I guess that might be censored too! This seems really really bad.
> In Bitcoin, miners can just join a different pool at a whim. There is not=
hing the attacker can do to stop them. A temporary dishonest majority heals=
 relatively well.
>
> There is another severe disadvantage to this on-chain delegation system: =
every UTXO must indicate which staking account this UTXO belongs to so the =
appropriate share of block rewards can be transferred there.
> Being able to associate every UTXO to an account ruins one of the main pr=
ivacy advantages of the UTXO model.
> It also grows the size of the blockchain significantly.
>
> ### "Pure" proof of stake (Algorand)
>
> Algorand's[4] approach is to only allow online stake to participate in th=
e protocol.
> Theoretically, This means that keys holding funds have to be online in or=
der for them to author blocks when they are chosen.
> Of course in reality no one wants to keep their coin holding keys online =
so in Alogorand you can authorize a set of "participation keys"[1] that wil=
l be used to create blocks on your coin holding key's behalf.
> Hopefully you've spotted the problem.
> You can send your participation keys to any malicious party with a nice w=
ebsite (see random example [2]) offering you a good return.
> Damn it's still Proof-of-SquareSpace!
> The minor advantage is that at least the participation keys expire after =
a certain amount of time so eventually the SquareSpace attacker will lose t=
heir hold on consensus.
> Importantly there is also less junk on the blockchain because the partici=
pation keys are delegated off-chain and so are not making as much of a mess=
.
>
> ### Conclusion
>
> I don't see a way to get around the conflicting requirement that the keys=
 for large amounts of coins should be kept offline but those are exactly th=
e coins we need online to make the scheme secure.
> If we allow delegation then we open up a new social attack surface and it=
 degenerates to Proof-of-SquareSpace.
>
> For a "digital gold" like system like Bitcoin we optimize for simplicity =
and desperately want to avoid extraneous responsibilities for the holder of=
 the coin.
> After all, gold is an inert element on the periodic table that doesn't co=
nfer responsibilities on the holder to maintain the quality of all the othe=
r bars of gold out there.
> Bitcoin feels like this too and in many ways is more inert and beautifull=
y boring than gold.
> For Bitcoin to succeed I think we need to keep it that way and Proof-of-S=
take makes everything a bit too exciting.
>
> I suppose in the end the market will decide what is real digital gold and=
 whether these bad technical trade offs are worth being able to say it uses=
 less electricity. It goes without saying that making bad technical decisio=
ns to appease the current political climate is an anathema to Bitcoin.
>
> Would be interested to know if you or others think differently on these p=
oints.
>
> [1]: https://developer.algorand.org/docs/run-a-node/participate/generate_=
keys/
> [2]: https://staking.staked.us/algorand-staking
> [3]: https://eprint.iacr.org/2017/573.pdf
> [4]: https://algorandcom.cdn.prismic.io/algorandcom%2Fece77f38-75b3-44de-=
bc7f-805f0e53a8d9_theoretical.pdf
> [5]: https://hydra.iohk.io/build/790053/download/1/delegation_design_spec=
.pdf
>
> Cheers,
>
> LL
>
> On Fri, 21 May 2021 at 19:21, Billy Tetrud via bitcoin-dev <bitcoin-dev@l=
ists.linuxfoundation.org> wrote:
>>
>> I think there is a lot of misinformation and bias against Proof of Stake=
. Yes there have been lots of shady coins that use insecure PoS mechanisms.=
 Yes there have been massive issues with distribution of PoS coins (of cour=
se there have also been massive issues with PoW coins as well). However, I =
want to remind everyone that there is a difference between "proved to be im=
possible" and "have not achieved recognized success yet". Most of the argum=
ents levied against PoS are out of date or rely on unproven assumptions or =
extrapolation from the analysis of a particular PoS system. I certainly don=
't think we should experiment with bitcoin by switching to PoS, but from my=
 research, it seems very likely that there is a proof of stake consensus pr=
otocol we could build that has substantially higher security (cost / capita=
l required to execute an attack) while at the same time costing far less re=
sources (which do translate to fees on the network) *without* compromising =
any of the critical security properties bitcoin relies on. I think the crit=
ical piece of this is the disagreements around hardcoded checkpoints, which=
 is a critical piece solving attacks that could be levied on a PoS chain, a=
nd how that does (or doesn't) affect the security model.
>>
>> @Eric Your proof of stake fallacy seems to be saying that PoS is worse w=
hen a 51% attack happens. While I agree, I think that line of thinking omit=
s important facts:
>> * The capital required to 51% attack a PoS chain can be made substantial=
ly greater than on a PoS chain.
>> * The capital the attacker stands to lose can be substantially greater a=
s well if the attack is successful.
>> * The effectiveness of paying miners to raise the honest fraction of min=
ers above 50% may be quite bad.
>> * Allowing a 51% attack is already unacceptable. It should be considered=
 whether what happens in the case of a 51% may not be significantly differe=
nt. The currency would likely be critically damaged in a 51% attack regardl=
ess of consensus mechanism.
>>
>> > Proof-of-stake tends towards oligopolistic control
>>
>> People repeat this often, but the facts support this. There is no centra=
lization pressure in any proof of stake mechanism that I'm aware of. IE if =
you have 10 times as much coin that you use to mint blocks, you should expe=
ct to earn 10x as much minting revenue - not more than 10x. By contrast, pr=
oof of work does in fact have clear centralization pressure - this is not d=
isputed. Our goal in relation to that is to ensure that the centralization =
pressure remains insignifiant. Proof of work also clearly has a lot more ba=
rriers to entry than any proof of stake system does. Both of these mean the=
 tendency towards oligopolistic control is worse for PoW.
>>
>> > Energy usage, in-and-of-itself, is nothing to be ashamed of!!
>>
>> I certainly agree. Bitcoin's energy usage at the moment is I think quite=
 warranted. However, the question is: can we do substantially better. I thi=
nk if we can, we probably should... eventually.
>>
>> > Proof of Stake is only resilient to =E2=85=93 of the network demonstra=
ting a Byzantine Fault, whilst Proof of Work is resilient up to the =C2=BD =
threshold
>>
>> I see no mention of this in the pos.pdf you linked to. I'm not aware of =
any proof that all PoS systems have a failure threshold of 1/3. I know that=
 staking systems like Casper do in fact have that 1/3 requirement. However =
there are PoS designs that should exceed that up to nearly 50% as far as I'=
m aware. Proof of work is not in fact resilient up to the 1/2 threshold in =
the way you would think. IE, if 100% of miners are currently honest and hav=
e a collective 100 exahashes/s hashpower, an attacker does not need to obta=
in 100 exahashes/s, but actually only needs to accumulate 50 exahashes/s. T=
his is because as the attacker accumulates hashpower, it drives honest mine=
rs out of the market as the difficulty increases to beyond what is economic=
ally sustainable. Also, its been shown that the best proof of work can do i=
s require an attacker to obtain 33% of the hashpower because of the selfish=
 mining attack discussed in depth in this paper: https://arxiv.org/abs/1311=
.0243. Together, both of these things reduce PoW's security by a factor of =
about 83% (1 - 50%*33%).
>>
>>  > Proof of Stake requires other trade-offs which are incompatible with =
Bitcoin's objective (to be a trustless digital cash) =E2=80=94 specifically=
 the famous "security vs. liveness" guarantee
>>
>> Do you have a good source that talks about why you think proof of stake =
cannot be used for a trustless digital cash?
>>
>> > You cannot gain tokens without someone choosing to give up those coins=
 - a form of permission.
>>
>> This is not a practical constraint. Just like in mining, some nodes may =
reject you, but there will likely be more that will accept you, some seller=
s may reject you, but most would accept your money as payment for bitcoins.=
 I don't think requiring the "permission" of one of millions of people in t=
he market can be reasonably considered a "permissioned currency".
>>
>> > 2. Proof of stake must have a trusted means of timestamping to regulat=
e overproduction of blocks
>>
>> Both PoW and PoS could mine/mint blocks twice as fast if everyone agreed=
 to double their clock speeds. Both systems rely on an honest majority stic=
king to standard time.
>>
>>
>> On Wed, May 19, 2021 at 5:32 AM Michael Dubrovsky via bitcoin-dev <bitco=
in-dev@lists.linuxfoundation.org> wrote:
>>>
>>> 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> wrot=
e:
>>>>
>>>> Folks, I suggest we keep the discussion to PoW, oPoW, and the BIP itse=
lf. PoS, VDFs, and so on are interesting but I guess there are other thread=
s going on these topics already where they would be relevant.
>>>>
>>>> Also, it's important to distinguish between oPoW and these other "alte=
rnatives" 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 ris=
k
>>>>> 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> wr=
ote:
>>>>> >
>>>>> > 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> wr=
ote:
>>>>> >>
>>>>> >> Good morning Zac,
>>>>> >>
>>>>> >> > VDFs might enable more constant block times, for instance by hav=
ing a two-step PoW:
>>>>> >> >
>>>>> >> > 1. Use a VDF that takes say 9 minutes to resolve (VDF being subj=
ect 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 adjustme=
nts.
>>>>> >> >
>>>>> >> > 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 i=
nherently 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 circu=
itry), could potentially get into a winner-takes-all situation, possibly le=
ading to even *worse* competition and even *more* energy consumption.
>>>>> >> After all, if you can start mining 0.1s faster than the competitio=
n, 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
>>>
>>>
>>>
>>> --
>>> Michael Dubrovsky
>>> Founder; PoWx
>>> www.PoWx.org
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev