From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 23FFFC0001 for ; Sun, 23 May 2021 19:29:06 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 1B3C1832C2 for ; Sun, 23 May 2021 19:29:06 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 wyHZHPN44mwq for ; Sun, 23 May 2021 19:29:03 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) by smtp1.osuosl.org (Postfix) with ESMTPS id D5B76832E6 for ; Sun, 23 May 2021 19:29:02 +0000 (UTC) Received: by mail-ed1-x52d.google.com with SMTP id s6so29330474edu.10 for ; Sun, 23 May 2021 12:29:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nfFfKbUHdX9SAnkao2GD9TungHjGO27NVsUrDRcfZKw=; b=eV5pMTMYfXtpvv18I7+hXCCQvIeJyejX0Y7aKV3C+p/sSxnJzZLMBuzzxFpYdFvyky 21D/aVlOkLiF7DWjjfsprLpcSgm0/ySF5oeLdaAMg1N/PZ1gy9L+OQTBr2O1o1Y5KA+Q q/Rl3G/SVqrqH1eWyvimANRTsQtvT7FMz4jOJE3ymNKIF7/Wi6KPrkLgZJ+5fHdflf+8 LZHlPhVdzguGOEd9/thEcAkOEVeeUFVS8K8jN+3EaJq6FavPPnf2M8W8OieTKBN7Nhax fGmrUwknNuRx2X9LylKWq/Gb4geC8PVK1CNKjR/VFKHiYin/5JS0fejvLi9Eir+PFUJQ B5nw== 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; bh=nfFfKbUHdX9SAnkao2GD9TungHjGO27NVsUrDRcfZKw=; b=TGldNLV7s3FafBWaJuDBk3o2CZlpij9ayoca6VGNkURnTQ3cdDt7Pe1MvHWYNsUlWq gcpDslTv/3ZyLSFVSg7ko4CMroR20HxlJZyOeL0SC07mI2UxDqJnDkwhSX+4Qv0tUvDK +x9drtuHTKxAUp9F3fzisx6ZfmNCdHzgd07n8G+NVzOU3h4zWqFPllMR01Nq3md5ewQf Dqxj4jCXBaX1DrImsGCaCa0J7TLJuxESYwQ5plUlIhVrZbV2c9E+ssOnxqBQRor/MDLQ toZSMuBDJchgmiGRX5vOb9fKMaWJuTrKj6GDoyAo7VhBaBb15O+27SS+8CRYYnEOf7fB U7JA== X-Gm-Message-State: AOAM533MRLYgbTkfAPYBTPx/PYRpZr+eoku0/WOogTpab7clKr+9cz/q NFs16WquMNPsscadtPIfCK7deG2aku8KnH7l460= X-Google-Smtp-Source: ABdhPJz0jrQAe42oUyFCO8br3fA1D+MFlUtF39PYtIFCQXeKjLYAwN6REYtKHCBRt4AVX6duzIEkKuLtM2kPw1GI0IE= X-Received: by 2002:a05:6402:190e:: with SMTP id e14mr22118339edz.146.1621798141005; Sun, 23 May 2021 12:29:01 -0700 (PDT) MIME-Version: 1.0 References: <6do5xN2g5LPnFeM55iJ-4C4MyXOu_KeXxy68Xt4dJQMhi3LJ8ZrLICmEUlh8JGfDmsDG12m1JDAh0e0huwK_MlyKpdfn22ru3zsm7lYLfBo=@protonmail.com> <30li5MRxkBhzLxLmzRnHkCdn8n3Feqegi-FLZ5VDyIX2uRJfq4kVtrsLxw6dUtsM1atYV25IfIfDaQp4s2Dn2vc8LvYkhbAsn0v_Fwjerpw=@protonmail.com> In-Reply-To: From: Billy Tetrud Date: Sun, 23 May 2021 09:28:43 -1000 Message-ID: To: Lloyd Fournier Content-Type: multipart/alternative; boundary="00000000000017943c05c3044edf" X-Mailman-Approved-At: Sun, 23 May 2021 19:37:19 +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: Sun, 23 May 2021 19:29:06 -0000 --00000000000017943c05c3044edf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I made a couple typos and mistakes in my couple previous emails: * "People repeat this often, but the facts support this" -> "the facts *don= 't *support this" * "Together, both of these things reduce PoW's security by a factor of about 83% (1 - 50%*33%)." -> "factor of about 83% (1 - 50%**(50% - 33%)/50%= *)." (I made a mistake that happened to come out to an almost identical result coincidentally). * "And pools could simply require full custody of the coins." -> "*But *poo= ls could..." On Sun, May 23, 2021 at 9:10 AM Billy Tetrud wrote= : > @Lloyd > > > Proof-of-SquareSpace > > I agree with your points about delegated proof of stake. I wrote my own > critique about that > as > well. And your point, that other forms of PoS devolve to DPoS by virtue o= f > people wanting to actively mint blocks without exposing their coins in ho= t > wallets, is an interesting one. > > > how are the users meant to redelegate their stake to honest pools? > > This could be mitigated partially if delegation didn't require any kind o= f > blockchain transaction. For example, users could simply send a signed > message saying "this other key can mint blocks with my coins", and then > minting a block using those coins would require presenting the delegation > signature. This only partially mitigates the problem since the dishonest > pool would still be able to use those coins as well, so it would be a rac= e > at that point. Still better than nothing. And pools could simply require > full custody of the coins. > > From what you mentioned, it sounds like maybe Algorand does something > similar to this. > > > 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 the coins we need online to make the scheme secure. > > There are a couple solutions you didn't mention. One is your "traditional= " > locked-stake kind of systems, where participants are required to lock the= ir > stake for long periods of time. Since normal users aren't likely to want = to > do this, it will likely be left to more sophisticated stakers likely > staking very large amounts. > > Both mechanisms you mentioned allow delegation, and it might seem like > maybe there'd be a way to disallow delegation, however since users can > always give custody of their coins to trusted pools, that would be a > delgation mechanism of last resort that can't be removed. So you can do > things that make it hard (for both users and pool operators) to delegate > trustlessly, but you can't get rid of the ability to delgate entirely. > > In general, the situations where I see people not pooling are: > > A. They are entirely prevented by technical means. It seems reasonably > clear that this is impossible. > B. The downsides are more than unsophisticated users are willing to incur > (eg stake locking). > C. The rewards are so small that it isn't worth it for people to put in > much effort to gain them. > D. The rewards are so frequent that pooling is unnecessary. > > B excludes a lot of people from being able to help secure the chain, but > this is not materially different from PoW mining in that regard. D is a b= it > border line. With 1 billion people attempting to participate and 10 minut= e > blocks, 232 people would need to share the block reward in order to expec= t > a payout on average once per month. With 8 billion people that would turn > into more like 1700 people. This seems potentially doable (eg via cosigne= r > requirements on minted blocks), but it is a lot of participants per block= . > > I think options C and D combined would be an ideal approach here. Because > minting uses very few real resources, minting could be pretty much have > arbitrarily low ongoing costs. This means fees can be low and blocks can > have low payouts. If the reward was low and people could expect to see it > once every couple years, people could simply treat it like a lottery. Gre= at > if they win it now, but nothing that anyone needs to rely on (which would > incentivize the pools to reduce variance that we want to avoid). If there > is no locked stake or other major barriers in place to minting blocks, th= at > would also help avoid the compultion to use a pool. > > In any case, you bring up good points, and they certainly complicate the > issue. By the way, if you were confused as to what VPoS was in the sectio= n > from my above link, this might satisfy your curiosity > . > > Cheers > > > > > On Sat, May 22, 2021 at 5:41 PM Lloyd Fournier > 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 >> inappropriate 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 >> 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 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 >> within the security claims made in their papers. >> People who believe that these protocols are destined for catastrophic >> 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 stake >> protocols would have on Bitcoin: >> >> ### Proof of SquareSpace (Cardano, Polkdadot) >> >> Cardano is a UTXO based PoS coin based on Ouroboros Praos[3] with an >> 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 choose = a >> pool by looking around for one with a nice website and offering the larg= est >> 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 >> differences: >> >> 1. The person making the decision is forced into it just because they ow= n >> the currency -- someone with a mining rig has purchased it with the inte= nt >> to make profit by participating in consensus. >> >> 2. When you join a mining pool your systems are very much still online. >> You are just partaking in a pool to reduce your profit variance. You sti= ll >> see every block that you help create and *you never help create a block >> without seeing it first*. >> >> 3. If by SquareSpace sybil attack you gain a dishonest majority and star= t >> censoring transactions how are the users meant to redelegate their stake= 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 system: >> every UTXO must indicate which staking account this UTXO belongs to so t= he >> appropriate share of block rewards can be transferred there. >> Being able to associate every UTXO to an account ruins one of the main >> 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 online >> so in Alogorand you can authorize a set of "participation keys"[1] that >> 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 los= e >> their hold on consensus. >> Importantly there is also less junk on the blockchain because the >> participation 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 key= s >> for large amounts of coins should be kept offline but those are exactly = the >> coins we need online to make the scheme secure. >> If we allow delegation then we open up a new social attack surface and i= t >> 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 >> confer responsibilities on the holder to maintain the quality of all the >> other bars of gold out there. >> Bitcoin feels like this too and in many ways is more inert and >> beautifully boring than gold. >> For Bitcoin to succeed I think we need to keep it that way and >> Proof-of-Stake makes everything a bit too exciting. >> >> I suppose in the end the market will decide what is real digital gold an= d >> whether these bad technical trade offs are worth being able to say it us= es >> less electricity. It goes without saying that making bad technical >> decisions to appease the current political climate is an anathema to >> Bitcoin. >> >> Would be interested to know if you or others think differently on these >> points. >> >> [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@lists.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 course 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 impossible" and "have not achieved recognized suc= cess >>> yet". Most of the arguments 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 protocol we could build that has substantial= ly >>> higher security (cost / capital required to execute an attack) while at= the >>> same time costing far less resources (which do translate to fees on the >>> network) *without* compromising any of the critical security properties >>> bitcoin relies on. I think the critical piece of this is the disagreeme= nts >>> around hardcoded checkpoints, which is a critical piece solving attacks >>> that could be levied on a PoS chain, and how that does (or doesn't) aff= ect >>> the security model. >>> >>> @Eric Your proof of stake fallacy seems to be saying that PoS is worse >>> when a 51% attack happens. While I agree, I think that line of thinking >>> omits important facts: >>> * The capital required to 51% attack a PoS chain can be made >>> substantially greater than on a PoS chain. >>> * The capital the attacker stands to lose can be substantially greater >>> 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 considere= d >>> whether what happens in the case of a 51% may not be significantly >>> different. The currency would likely be critically damaged in a 51% att= ack >>> regardless 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 >>> should expect to earn 10x as much minting revenue - not more than 10x. = By >>> contrast, proof of work does in fact have clear centralization pressure= - >>> this is not disputed. Our goal in relation to that is to ensure that th= e >>> centralization pressure remains insignifiant. Proof of work also clearl= y >>> has a lot more barriers to entry than any proof of stake system does. B= oth >>> of these mean the tendency towards oligopolistic control is worse for P= oW. >>> >>> > 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 quit= e >>> 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 demonstr= ating a >>> Byzantine Fault, whilst Proof of Work is resilient up to the =C2=BD thr= eshold >>> >>> 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 t= o >>> 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 have a collective 100 exahashes/s hashpower, an >>> attacker does not need to obtain 100 exahashes/s, but actually only nee= ds >>> to accumulate 50 exahashes/s. This is because as the attacker accumulat= es >>> hashpower, it drives honest miners out of the market as the difficulty >>> increases to beyond what is economically sustainable. Also, its been sh= own >>> that the best proof of work can do is 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 specific= ally 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 coin= s >>> - 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 >>> sellers may reject you, but most would accept your money as payment for >>> bitcoins. I don't think requiring the "permission" of one of millions o= f >>> people in the market can be reasonably considered a "permissioned >>> currency". >>> >>> > 2. Proof of stake must have a trusted means of timestamping to >>> regulate overproduction of blocks >>> >>> Both PoW and PoS could mine/mint blocks twice as fast if everyone agree= d >>> to double their clock speeds. Both systems rely on an honest majority >>> sticking to standard time. >>> >>> >>> On Wed, May 19, 2021 at 5:32 AM Michael Dubrovsky via bitcoin-dev < >>> bitcoin-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 >>>> 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 ot= her >>>>> 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, th= e >>>>>> value gained from proof of work... without some of the security >>>>>> drawbacks >>>>>> - the miner risks losing all of his burned coins (like all miners ri= sk >>>>>> 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 spu= n >>>>>> 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 >>>>>> 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 c= onstant. >>>>>> > >>>>>> > 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 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; the= y are >>>>>> inherently progress-requiring). >>>>>> >> >>>>>> >> Thus, a miner which focuses on improving the amount of energy tha= t >>>>>> 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 >>>>> >>>> >>>> >>>> -- >>>> 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 >>> >> --00000000000017943c05c3044edf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I made a couple typos and mistakes in my couple previous e= mails:

* "People repeat this often, but the facts supp= ort this" -> "the facts don't support this"
* "Together, both of these things reduce PoW's = security by a factor of about 83% (1 - 50%*33%)." -> "factor o= f about 83% (1 - 50%*(50% - 33%)/50%)." (I made a mistake that = happened to come out to an almost identical result coincidentally).=C2=A0
* "And pools could simply require full custody of the coins.&= quot; -> "But pools could..."

On Sun, May 23, 2021= at 9:10 AM Billy Tetrud <bill= y.tetrud@gmail.com> wrote:
@Lloyd

>=C2= =A0 Proof-of-SquareSpace

I agree with your points about dele= gated proof of stake. I wrote my own critique about that=C2=A0as well. And y= our point, that other forms of PoS devolve to DPoS by virtue of people want= ing to actively mint blocks without exposing their coins in hot wallets, is= an interesting one.=C2=A0

> how are the users = meant to redelegate their stake to honest pools?

This could be mitigated partially if delegation=C2=A0didn't require = any kind of blockchain transaction. For example, users could simply send a = signed message saying "this other key can mint blocks with my coins&qu= ot;, and then minting a block using those coins would require presenting th= e delegation signature. This only partially mitigates the problem since the= dishonest pool would still be able to use those coins as well, so it would= be a race at that point. Still better than nothing. And pools could simply= require full custody of the coins.

From what you = mentioned, it sounds like maybe Algorand does something similar to this.=C2= =A0

> I don't see a way to get around the c= onflicting requirement that the keys for large amounts of coins should be k= ept offline but those are exactly the coins we need online to make the sche= me secure.

There are a couple solutions you didn&#= 39;t mention. One is your "traditional" locked-stake kind of syst= ems, where participants are required to lock their stake for long periods o= f time. Since normal users aren't likely to want to do this, it will li= kely be left to more sophisticated stakers likely staking very large amount= s.=C2=A0

Both mechanisms you mentioned allow deleg= ation, and it might seem like maybe there'd be a way to disallow delega= tion, however since users can always give custody of their coins to trusted= pools, that would be a delgation mechanism of last resort that can't b= e removed. So you can do things that make it hard (for both users and pool = operators) to delegate trustlessly, but you can't get rid of the abilit= y to delgate entirely.

In general, the situations = where I see people not pooling are:

A. They are en= tirely prevented by technical means. It seems reasonably clear that this is= impossible.
B. The downsides are more than unsophisticated users= are willing to incur (eg stake locking).
C. The rewards are so s= mall that it isn't worth it for people to put in much effort to gain th= em.
D. The rewards are so frequent that pooling is unnecessary.

B excludes a lot of people from being able to help = secure the chain, but this is not materially different from PoW mining in t= hat regard. D is a bit border line. With 1 billion people attempting to par= ticipate and 10 minute blocks, 232 people would need to share the block rew= ard in order to expect a payout on average once per month. With 8 billion p= eople that would turn into more like 1700 people. This seems potentially do= able (eg via cosigner requirements on minted blocks), but it is a lot of pa= rticipants per block.=C2=A0

I think options C and = D combined would be an ideal approach here. Because minting uses very few r= eal resources, minting could be pretty much have arbitrarily low ongoing co= sts. This means fees can be low and blocks can have low payouts. If the rew= ard was low and people could expect to see it once every couple years, peop= le could simply treat it like a lottery. Great if they win it now, but noth= ing that anyone needs to rely on (which would incentivize the pools to redu= ce variance that we want to avoid). If there is no locked stake or other ma= jor barriers in place to minting blocks, that would also help avoid the com= pultion to use a pool.

In any case, you bring up g= ood points, and they certainly complicate the issue. By the way, if you wer= e confused as to what VPoS was in the section from my above link, this might satisfy your curiosity.

Cheers




On Sat, May 22, 2021 at 5:41= PM Lloyd Fournier <lloyd.fourn@gmail.com> wrote:
Hi Billy,

I was = going to write a post which started by dismissing many of the weak argument= s 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 inappropria= te 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 g= old") which is what Bitcoin is trying to be.
PoS necessarily gives = responsibilities to the holders of coins that they do not want and cannot h= andle.
In Bitcoin, large unsophisticated coin holders can put their coin= s in cold storage without a second thought given to the health of the under= lying ledger.
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 its= elf).
In PoS systems this clean separation of responsibilities does not = exist.

I think that the more rigorously studied PoS = protocols will work fine within the security claims made in their papers.
People who believe that these protocols are destined for catastrop= hic consensus failure are certainly in for a surprise.
But the de= vil is in the detail.
Let's look at what the implications of u= sing the leading proof of stake protocols would have on Bitcoin:

###= Proof of SquareSpace (Cardano, Polkdadot)

Cardano is a UTXO based P= oS coin based on Ouroboros Praos[3] with an inbuilt on-chain delegation sys= tem[5].
In these protocols, coin holders who do not want to run their no= de with their hot keys in it delegate it to a "Stake Pool".
I = call the resulting system Proof-of-SquareSpace since most will choose a poo= l by looking around for one with a nice website and offering the largest sh= are of the block reward.
On the surface this might sound no different th= an someone with an mining rig shopping around for a good mining pool but th= ere are crucial differences:

1. The person making the decision is fo= rced into it just because they own the currency -- someone with a mining ri= g has purchased it with the intent to make profit by participating in conse= nsus.

2. When you join a mining pool your systems are very much stil= l online. You are just partaking in a pool to reduce your profit variance. = You still see every block that you help create and *you never help create a= block without seeing it first*.

3. If by SquareSpace sybil attack y= ou gain a dishonest majority and start censoring transactions how are the u= sers meant to redelegate their stake to honest pools?
I guess they can j= ust send a transaction delegating to another pool...oh wait I guess that mi= ght be censored too! This seems really really bad.
In Bitcoin, miners ca= n just join a different pool at a whim. There is nothing the attacker can d= o 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 privacy advanta= ges of the UTXO model.
It also grows the size of the blockchain signific= antly.

### "Pure" proof of stake (Algorand)

Algoran= d's[4] approach is to only allow online stake to participate in the pro= tocol.
Theoretically, This means that keys holding funds have to be onli= ne in order 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 Alogoran= d you can authorize a set of "participation keys"[1] that 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 y= ou a good return.
Damn it's still Proof-of-SquareSpace!
The minor= advantage is that at least the participation keys expire after a certain a= mount of time so eventually the SquareSpace attacker will lose their hold o= n consensus.
Importantly there is also less junk on the blockchain becau= se the participation keys are delegated off-chain and so are not making as = much of a mess.

### Conclusion

I don't see a way to get a= round the conflicting requirement that the keys for large amounts of coins = should be kept offline but those are exactly the coins we need online to ma= ke 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 optim= ize for simplicity and desperately want to avoid extraneous responsibilitie= s for the holder of the coin.
After all, gold is an inert element on the= periodic table that doesn't confer responsibilities on the holder to m= aintain the quality of all the other bars of gold out there.
Bitcoin fee= ls like this too and in many ways is more inert and beautifully boring than= gold.
For Bitcoin to succeed I think we need to keep it that way a= nd Proof-of-Stake 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 u= ses less electricity. It goes without saying that making bad technical deci= sions to appease the current political climate is an anathema to Bitcoin.

Would be interested to know if you or others th= ink differently on these points.

[1]: https://developer.algorand.org/docs/run-a-node/participate/generate_ke= ys/
[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

Cheers,

LL
<= br>
On Fri,= 21 May 2021 at 19:21, Billy Tetrud via bitcoin-dev <bitcoin-dev@lists.l= inuxfoundation.org> wrote:
I think there is a lot of misinform= ation and bias against Proof of Stake. Yes there have been lots of shady co= ins that use insecure PoS mechanisms. Yes there have been massive issues wi= th distribution of PoS coins (of course 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 impossible" and "have not= achieved recognized success yet". Most of the arguments levied agains= t 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 sh= ould experiment with bitcoin by switching to PoS, but from my research, it = seems very likely that there is a proof of stake consensus protocol we coul= d build that has substantially higher security (cost / capital required to = execute an attack) while at the same time costing far less resources (which= do translate to fees on the network) *without* compromising any of the cri= tical security properties bitcoin relies on. I think the critical piece of = this is the disagreements around hardcoded checkpoints, which is a critical= piece solving=C2=A0attacks that=C2=A0could be levied on a PoS chain, and h= ow that does (or doesn't) affect the security model.=C2=A0
@Eric Your proof of stake fallacy seems to be saying that PoS is wo= rse when a 51% attack happens. While I agree, I think that line of thinking= omits important facts:
* The capital=C2=A0required to 51% attack a PoS = chain can be made substantially greater than on a PoS chain.=C2=A0
* Th= e capital the attacker stands to lose can be substantially greater as well = if the attack is successful.
* The effectiveness of paying miners t= o raise the honest fraction of miners above 50% may be quite bad.
* Allowing a 51% attack is already unacceptable. It should be considered w= hether what happens in the case of a 51% may not be significantly different= . The currency would likely be critically damaged in a 51% attack regardles= s of consensus mechanism.

>=C2=A0Proof-of-stake te= nds towards oligopolistic control

People r= epeat this often, but the facts support this. There is no centralization pr= essure in any proof of stake mechanism that I'm aware of. IE if you hav= e 10 times as much coin that you use to mint blocks, you should expect to e= arn 10x as much minting revenue - not more than 10x. By contrast, 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 centralization pressur= e remains insignifiant. Proof of work also clearly has a lot more barriers = to entry than any proof of stake system does. Both of these mean the tenden= cy towards oligopolistic control is worse for PoW.

>=C2=A0Energy usage, in-and-of-itself, is nothing to be = ashamed of!!

I certainly agree. Bitcoin's=C2= =A0energy usage at the moment is I think quite warranted. However, the ques= tion is: can we do substantially better. I think if we can, we probably sho= uld... eventually.

> Proof of Stake is onl= y resilient to=C2=A0=E2=85=93 of the network demonstrating a Byzantine Faul= t, whilst Proof of Work is resilient up to the=C2=A0=C2=BD threshold
<= div>
I see no mention of this in the=C2=A0pos.pdf=C2= =A0you linked to. I'm not aware of any proof that all PoS system= s 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 sh= ould 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 have a collective 100 exahas= hes/s hashpower, an attacker does not need to obtain 100 exahashes/s, but a= ctually only needs to accumulate 50 exahashes/s. This is because as the att= acker accumulates hashpower, it drives honest miners out of the market as t= he difficulty increases to beyond what is economically sustainable. Also, i= ts been shown that the best proof of work can do is require an attacker to = obtain 33% of the hashpower because of the selfish mining attack=C2=A0discussed in depth i= n 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%).

<= /div>
=C2=A0> Proof of Stake requires other trade-offs which are inc= ompatible with Bitcoin's objective (to be a trustless digital cash) =E2= =80=94 specifically the famous "security vs. liveness" guarantee<= /div>

Do you have a good source that talks about why you= think proof of stake cannot be used for a trustless digital cash?=C2=A0

> You cannot gain tokens without someone choosing= to give up those coins - a form of permission.

Th= is is not a practical constraint. Just like in mining, some nodes may rejec= t 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 bitcoins. I do= n't think requiring the "permission" of one of millions of pe= ople in the market can be reasonably considered a "permissioned curren= cy".=C2=A0=C2=A0

> 2. Proof of stake= must have a trusted means of timestamping to regulate overproduction of bl= ocks

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 sticking to standard time.=C2=A0=C2=A0

On Wed, May 19, 2021 at 5:32 AM Michael Dubrovsky via bitcoin-= dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Ah sorry, I d= idn'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 d= iscussion to PoW, oPoW, and the BIP itself. PoS, VDFs, and so on are intere= sting but I guess there are other threads going on these topics already whe= re they would be relevant.=C2=A0

Also, it's importan= t=C2=A0to 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=C2=A0

On Tue, May 18, 2021 at 4:55 PM Erik Aro= nesty via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wro= te:
1. i never s= uggested 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<= br> 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.=C2=A0 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, b= ut 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 s= ubject 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 adjus= tments.
>> >
>> > 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/mail= man/listinfo/bitcoin-dev


--
Mich= ael Dubrovsky
Founder; PoWx
www.PoWx.org


--
Mich= ael Dubrovsky
Founder; PoWx
www.PoWx.org
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--00000000000017943c05c3044edf--