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 1F0F7C0001 for ; 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 ; 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 ; 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 ; Mon, 24 May 2021 13:47:35 +0000 (UTC) Received: by mail-pj1-x1036.google.com with SMTP id b15-20020a17090a550fb029015dad75163dso11190058pji.0 for ; 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> <30li5MRxkBhzLxLmzRnHkCdn8n3Feqegi-FLZ5VDyIX2uRJfq4kVtrsLxw6dUtsM1atYV25IfIfDaQp4s2Dn2vc8LvYkhbAsn0v_Fwjerpw=@protonmail.com> In-Reply-To: From: Erik Aronesty Date: Mon, 24 May 2021 09:47:24 -0400 Message-ID: To: Lloyd Fournier , Bitcoin Protocol Discussion 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 , Billy Tetrud 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: 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 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 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 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 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 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 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 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