From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id D6E41C0001 for ; Tue, 25 May 2021 13:00:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id B94F3403DF for ; Tue, 25 May 2021 13:00:25 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=q32-com.20150623.gappssmtp.com Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODuB9cXN6nur for ; Tue, 25 May 2021 13:00:23 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) by smtp4.osuosl.org (Postfix) with ESMTPS id A320C4039A for ; Tue, 25 May 2021 13:00:23 +0000 (UTC) Received: by mail-pj1-x1029.google.com with SMTP id j6-20020a17090adc86b02900cbfe6f2c96so13116454pjv.1 for ; Tue, 25 May 2021 06:00:23 -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=vwdoYEai3bOeWnQ4poDG2cv4sSf252fCFtMqqR4kB80=; b=VAv4zAiiWXF4PYkqwEzvXRl0cZgF+A4koMAxvAxEsrW+re5H9/aFGvyN1QVJ+w9ERK AafKaN7kroe6yTBLFqfShNUXfmFWXzkPn6l76yZDZ+eXVGjpTn3SjggGtCfFsbV8n0q/ hKs3qPKr9D9iLKvInGdRKHCqsGb6A4Zzc+f4Y2G0dHAh8TXwan9k7xOtD0kUecM4zSJw gkhmvwzcQgWgU7tJCg6QE54Wd9mW5EEluibCPbVOnAYSfIhEhro96D0Uw2JMAHx441Ia vvTJMQ7Mfm7Vj5eGxAdBIkb+TYNsWVaVG61AVMOHfeKpwBvvk4eaoZTyfkxldV+JFo3j h4Qg== 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=vwdoYEai3bOeWnQ4poDG2cv4sSf252fCFtMqqR4kB80=; b=XaY23OZAvl3AL3cicd95lKzedMnC8ts8bvcxxMaa1K7a8Arz4cqlfO1+1/rosFyhgW fECDIf4y5pIq2I68hFHY2RpxEw9C49rrmFRU390mOrneQ1j64TVq/tSx6lMM0hbS4OdC AMfmeyqFGu5oG9w6LzS/EGPuMG5LvHUda+/i2gpX0HCFHqvxsnFAhht8l5Zqe6jfOSZy 7lio4nu65IJG7QS/1g31x69CIiJ4EpyPKMXWlZukCQCjgUzzfmeHW1WjI/iBbirQDJ7S osR4nqurhtj/1scF2ixjjZ1hTISofpIBRd8hUUDIJJl8srvJ3lDW4kZlwZk3O91wpkIN QiUw== X-Gm-Message-State: AOAM533VX6f4C4O/xmwBkaiJ+4DiSP/G0sq48W7UHCVfD1LJAuta/PmQ zT8Kj/qD/w2enFrIghirAaXmSwx+CGjE5FbQ3ECmCTk= X-Google-Smtp-Source: ABdhPJzi5/0//vT07wvPUZgKpeJSU8FyuYgBoOrvQasJwOQDxL++7UW5RdIKpjFCRuQkAIdl+mtSSUdc0tknz1VYVTQ= X-Received: by 2002:a17:902:ec8a:b029:f8:dd34:25e9 with SMTP id x10-20020a170902ec8ab02900f8dd3425e9mr13970775plg.60.1621947622488; Tue, 25 May 2021 06:00:22 -0700 (PDT) MIME-Version: 1.0 References: <6do5xN2g5LPnFeM55iJ-4C4MyXOu_KeXxy68Xt4dJQMhi3LJ8ZrLICmEUlh8JGfDmsDG12m1JDAh0e0huwK_MlyKpdfn22ru3zsm7lYLfBo=@protonmail.com> <30li5MRxkBhzLxLmzRnHkCdn8n3Feqegi-FLZ5VDyIX2uRJfq4kVtrsLxw6dUtsM1atYV25IfIfDaQp4s2Dn2vc8LvYkhbAsn0v_Fwjerpw=@protonmail.com> In-Reply-To: From: Erik Aronesty Date: Tue, 25 May 2021 09:00:11 -0400 Message-ID: To: Billy Tetrud Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 25 May 2021 14:52:02 +0000 Cc: Bitcoin Protocol Discussion , SatoshiSingh 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 May 2021 13:00:26 -0000 > > you burn them to be used at a future particular block height > This sounds exploitable. It seems like an attacker could simply focus all= their burns on a particular set of 6 blocks to double spend, minimizing th= eir cost of attack. could be right. the original idea was to have burns decay over time, like ASIC's. anyway the point was not that "i had a magic formula" the point was that proof of burn is almost always better than proof of stake - simply because the "proof" is on-chain, not sitting on a node somewhere waiting to be stolen. On Mon, May 24, 2021 at 9:53 PM Billy Tetrud wrote= : > > Is this the kind of proof of burn you're talking about? > > > if i have a choice between two chains, one longer and one shorter, i = can only choose one... deterministically > > What prevents you from attempting to mine block 553 on both chains? > > > miners have a very strong, long-term, investment in the stability of th= e chain. > > Yes, but the same can be said of any coin, even ones that do have the not= hing at stake problem. This isn't sufficient tho because the chain is a com= mon good, and the tragedy of the commons holds for it. > > > you burn them to be used at a future particular block height > > This sounds exploitable. It seems like an attacker could simply focus all= their burns on a particular set of 6 blocks to double spend, minimizing th= eir cost of attack. > > > i can imagine scenarios where large stakeholders can collude to punish = smaller stakeholders simply to drive them out of business, for example > > Are you talking about a 51% attack? This is possible in any decentralized= cryptocurrency. > > > On Mon, May 24, 2021 at 11:49 AM Erik Aronesty wrote: >> >> > > 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 >> > I'm fuzzy on how proof of burn works. >> >> when you burn coins, you burn them to be used at a future particular >> block height: so if i'm burning for block 553, i can only use them to >> mine block 553. if i have a choice between two chains, one longer >> and one shorter, i can only choose one... deterministically, for that >> burn: the chain with the height 553. if we fix the "lead time" for >> burned coins to be weeks or even months in advance, miners have a very >> strong, long-term, investment in the stability of the chain. >> >> therefore there is no "nothing at stake" problem. it's >> deterministic, so miners have no choice. they can *only* choose the >> transactions that go into the block. they cannot choose which chain >> to mine, and it's time-locked, so rollbacks and instability always >> hurt miners the most. >> >> the "punishment" systems of PoS are "weird at best", certainly >> unproven. i can imagine scenarios where large stakeholders can >> collude to punish smaller stakeholders simply to drive them out of >> business, for example. and then you have to put checks in place to >> prevent that, and more checks for those prevention system... >> >> in PoB, there is no complexity. simpler systems like this are >> typically more secure. >> >> PoB also solves problems caused by "energy dependence", which could >> lead to state monopolies on mining (like the new Bitcoin Mining >> Council). these consortiums, if state sanctioned, could become a >> source of censorship, for example. Since PoB doesn't require you to >> have a live, well-connected node, it's harder to censor & harder to >> trace. >> >> Eliminating this weakness seems to be in the best interests of >> existing stakeholders >> >> >> >> >> On Mon, May 24, 2021 at 4:44 PM Billy Tetrud wr= ote: >> > >> > > proof of burn clearly solves this, since nothing is held online >> > >> > Well.. the coins to be burned need to be online when they're burned. B= ut yes, only a small fraction of the total coins need to be online. >> > >> > > 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 >> > >> > So you're saying that if say someone tries to mine a block on a shorte= r chain, that requires them to send a transaction burning their coins, and = that transaction could also be spent on the longest chain, which means thei= r coins are burned even if the chain they tried to mine on doesn't win? I'm= fuzzy on how proof of burn works. >> > >> > > proof of burn can be more secure than proof-of-stake >> > >> > FYI, proof of stake can be done without the "nothing at stake" problem= . You can simply punish people who mint on shorter chains (by rewarding peo= ple who publish proofs of this happening on the main chain). In quorum-base= d PoS, you can punish people in the quorum that propose or sign multiple bl= ocks for the same height. The "nothing at stake" problem is a solved proble= m at this point for PoS. >> > >> > >> > >> > On Mon, May 24, 2021 at 3:47 AM Erik Aronesty wrote: >> >> >> >> > I don't see a way to get around the conflicting requirement that th= e keys for large amounts of coins should be kept offline but those are exac= tly the 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 you= r 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 >> >> 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 here so I'll focus on the second part: why I think Proof-of-Stake is in= appropriate 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 try= ing 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 cold storage without a second thought given to the health of the underly= ing ledger. >> >> > As much as hardcore Bitcoiners try to convince them to run their ow= n node, most don't, and that's perfectly acceptable. >> >> > At no point do their personal decisions affect the underlying conse= nsus -- it only affects their personal security assurance (not that of the = system itself). >> >> > In PoS systems this clean separation of responsibilities does not e= xist. >> >> > >> >> > I think that the more rigorously studied PoS protocols will work fi= ne within the security claims made in their papers. >> >> > People who believe that these protocols are destined for catastroph= ic consensus 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 s= take protocols would have on Bitcoin: >> >> > >> >> > ### Proof of SquareSpace (Cardano, Polkdadot) >> >> > >> >> > Cardano is a UTXO based PoS coin based on Ouroboros Praos[3] with a= n inbuilt on-chain delegation system[5]. >> >> > In these protocols, coin holders who do not want to run their node = with their hot keys in it delegate it to a "Stake Pool". >> >> > I call the resulting system Proof-of-SquareSpace since most will ch= oose a pool by looking around for one with a nice website and offering the = largest share of the block reward. >> >> > On the surface this might sound no different than someone with an m= ining rig shopping around for a good mining pool but there are crucial diff= erences: >> >> > >> >> > 1. The person making the decision is forced into it just because th= ey 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 onl= ine. You are just partaking in a pool to reduce your profit variance. You s= till see every block that you help create and *you never help create a bloc= k without 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 s= take to 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 nothing the attacker can do to stop them. A temporary dishonest majority= heals relatively well. >> >> > >> >> > There is another severe disadvantage to this on-chain delegation sy= stem: every UTXO must indicate which staking account this UTXO belongs to s= o the appropriate share of block rewards can be transferred there. >> >> > Being able to associate every UTXO to an account ruins one of the m= ain privacy 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 the protocol. >> >> > Theoretically, This means that keys holding funds have to be online= in order for them to author blocks when they are chosen. >> >> > Of course in reality no one wants to keep their coin holding keys o= nline so in Alogorand you can authorize a set of "participation keys"[1] th= at will 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 website (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 their hold on consensus. >> >> > Importantly there is also less junk on the blockchain because the p= articipation 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 th= e keys for large amounts of coins should be kept offline but those are exac= tly the 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 simpl= icity and desperately want to avoid extraneous responsibilities for the hol= der of the coin. >> >> > After all, gold is an inert element on the periodic table that does= n't confer responsibilities on the holder to maintain the quality of all th= e other bars of gold out there. >> >> > Bitcoin feels like this too and in many ways is more inert and beau= tifully boring than gold. >> >> > For Bitcoin to succeed I think we need to keep it that way and Proo= f-of-Stake makes everything a bit too exciting. >> >> > >> >> > I suppose in the end the market will decide what is real digital go= ld and whether these bad technical trade offs are worth being able to say i= t uses less electricity. It goes without saying that making bad technical d= ecisions to appease the current political climate is an anathema to Bitcoin= . >> >> > >> >> > Would be interested to know if you or others think differently on t= hese points. >> >> > >> >> > [1]: https://developer.algorand.org/docs/run-a-node/participate/gen= erate_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_desig= n_spec.pdf >> >> > >> >> > Cheers, >> >> > >> >> > LL >> >> > >> >> > On Fri, 21 May 2021 at 19:21, Billy Tetrud via bitcoin-dev 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 mecha= nisms. Yes there have been massive issues with distribution of PoS coins (o= f course there have also been massive issues with PoW coins as well). Howev= er, I want to remind everyone that there is a difference between "proved to= be impossible" and "have not achieved recognized success yet". Most of the= arguments levied against PoS are out of date or rely on unproven assumptio= ns or extrapolation from the analysis of a particular PoS system. I certain= ly don't think we should experiment with bitcoin by switching to PoS, but f= rom my research, it seems very likely that there is a proof of stake consen= sus protocol we could build that has substantially higher security (cost / = capital required to execute an attack) while at the same time costing far l= ess resources (which do translate to fees on the network) *without* comprom= ising any of the critical security properties bitcoin relies on. I think th= e critical piece of this is the disagreements around hardcoded checkpoints,= which is a critical piece solving attacks that could be levied on a PoS ch= ain, and how that does (or doesn't) affect the security model. >> >> >> >> >> >> @Eric Your proof of stake fallacy seems to be saying that PoS is w= orse when a 51% attack happens. While I agree, I think that line of thinkin= g omits important facts: >> >> >> * The capital required to 51% attack a PoS chain can be made subst= antially greater than on a PoS chain. >> >> >> * The capital the attacker stands to lose can be substantially gre= ater as well if the attack is successful. >> >> >> * The effectiveness of paying miners to raise the honest fraction = of miners above 50% may be quite bad. >> >> >> * Allowing a 51% attack is already unacceptable. It should be cons= idered whether what happens in the case of a 51% may not be significantly d= ifferent. The currency would likely be critically damaged in a 51% attack r= egardless of consensus mechanism. >> >> >> >> >> >> > Proof-of-stake tends towards oligopolistic control >> >> >> >> >> >> People repeat this often, but the facts support this. There is no = centralization 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 shoul= d expect to earn 10x as much minting revenue - not more than 10x. By contra= st, proof of work does in fact have clear centralization pressure - this is= not disputed. Our goal in relation to that is to ensure that the centraliz= ation pressure remains insignifiant. Proof of work also clearly has a lot m= ore barriers to entry than any proof of stake system does. Both of these me= an 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 think if we can, we probably should... eventually. >> >> >> >> >> >> > Proof of Stake is only resilient to =E2=85=93 of the network dem= onstrating 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 awa= re of any proof that all PoS systems have a failure threshold of 1/3. I kno= w that staking systems like Casper do in fact have that 1/3 requirement. Ho= wever 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 thresho= ld in the way you would think. IE, if 100% of miners are currently honest a= nd have a collective 100 exahashes/s hashpower, an attacker does not need t= o obtain 100 exahashes/s, but actually only needs to accumulate 50 exahashe= s/s. This is because as the attacker accumulates hashpower, it drives hones= t miners out of the market as the difficulty increases to beyond what is ec= onomically sustainable. Also, its been shown that the best proof of work ca= n do is require an attacker to obtain 33% of the hashpower because of the s= elfish mining attack discussed in depth in this paper: https://arxiv.org/ab= s/1311.0243. Together, both of these things reduce PoW's security by a fact= or 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 specif= ically 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 node= s may reject you, but there will likely be more that will accept you, some = sellers may reject you, but most would accept your money as payment for bit= coins. I don't think requiring the "permission" of one of millions of peopl= e in the market can be reasonably considered a "permissioned currency". >> >> >> >> >> >> > 2. Proof of stake must have a trusted means of timestamping to r= egulate 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 majorit= y sticking to standard time. >> >> >> >> >> >> >> >> >> On Wed, May 19, 2021 at 5:32 AM Michael Dubrovsky via bitcoin-dev = 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 wrote: >> >> >>>> >> >> >>>> Folks, I suggest we keep the discussion to PoW, oPoW, and the BI= P 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 alte= r the core game theory or security assumptions of Hashcash and actually con= tains 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 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 t= o >> >> >>>>> acquire rewards, and so miners would have to burn coins, well i= n >> >> >>>>> advance, and hope that their burned coins got rewarded in some = far >> >> >>>>> future >> >> >>>>> - the point of burned coins is to mimic, in every meaningful wa= y, the >> >> >>>>> value gained from proof of work... without some of the security >> >> >>>>> drawbacks >> >> >>>>> - the miner risks losing all of his burned coins (like all mine= rs 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 mirro= r the >> >> >>>>> properties of PoW and the incentives Bitcoin uses to mine hones= tly. >> >> >>>>> >> >> >>>>> 3. i do believe it is *possible* that a "burned coin + vdf syst= em" >> >> >>>>> might be more secure in the long run, and that if the entire sp= ace >> >> >>>>> agreed that such an endeavor was worthwhile, a test net could b= e 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 "a= lt >> >> >>>>> coin" >> >> >>>>> >> >> >>>>> On Tue, May 18, 2021 at 10:02 AM Zac Greenwood 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 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 bein= g subject to difficulty adjustments similar to the as-is). As per the prope= rty of VDFs, miners are able show proof of work. >> >> >>>>> >> > >> >> >>>>> >> > 2. Use current PoW mechanism with lower difficulty so find= ing a block takes 1 minute on average, again subject to as-is difficulty ad= justments. >> >> >>>>> >> > >> >> >>>>> >> > As a result, variation in block times will be greatly redu= ced. >> >> >>>>> >> >> >> >>>>> >> As I understand it, another weakness of VDFs is that they ar= e not inherently progress-free (their sequential nature prevents that; they= are inherently progress-requiring). >> >> >>>>> >> >> >> >>>>> >> Thus, a miner which focuses on improving the amount of energ= y that it can pump into the VDF circuitry (by overclocking and freezing the= circuitry), could potentially get into a winner-takes-all situation, possi= bly leading to even *worse* competition and even *more* energy consumption. >> >> >>>>> >> After all, if you can start mining 0.1s faster than the comp= etition, 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