Re: [bitcoin-dev] Opinion on proof of stake in future

From: Billy Tetrud <billy.tetrud@gmail•com>
To: greg m <greg_not_so@hotmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Opinion on proof of stake in future
Date: Sat, 26 Jun 2021 09:26:12 -0700	[thread overview]
Message-ID: <CAGpPWDaPZP_Z4DwW9OPCF4C0LHbEFwk1o6jxtpF557tPij93Kg@mail.gmail.com> (raw)
In-Reply-To: <MN2PR10MB4030EBD14EF82E29CFEDD00FB1069@MN2PR10MB4030.namprd10.prod.outlook.com>

[-- Attachment #1: Type: text/plain, Size: 11888 bytes --]

I've created a thread on reddit where we can continue the conversation:
https://www.reddit.com/r/BitcoinDiscussion/comments/o8dvlo/bitcoindev_opinion_on_proof_of_stake_in_future/

On Fri, Jun 25, 2021 at 9:59 AM greg m <greg_not_so@hotmail•com> wrote:

> Where do we go from here? reddit?
>
> Happy Friday everyone!
> gm
>
> On Jun 25, 2021 12:08, Ruben Somsen via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> Hi all,
>
> Thanks for the lively discussion. On behalf of the bitcoin-dev moderators
> and with the readers of this mailing list in mind, we'd like to suggest
> finishing up this discussion. Of course there should be some room for
> exploring fringe ideas, but it should not dominate the mailing list either.
> Fun as it may be, perhaps it's time to get back to focusing on the topics
> that are more directly relevant to Bitcoin.
>
> Cheers,
> Ruben
>
> On Fri, Jun 25, 2021 at 9:29 AM yanmaani--- via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> No, that's not how it works.
>
> PoS is constitutionally incapable of producing any further consensus
> from its starting point. If you start out by hardcoding the bitcoin
> ledger state at June 1, 2021, then your PoS system will be unable to
> reach a global consensus as to what the state was on June 2, 2021.
>
> To get global consensus in PoS, you have to know which block came first.
> To reach a consensus on which block was first, you need to solve the
> timestamp problem. And to solve the timestamp problem, you need a
> consensus system. You'll notice that at no point does PoS provide such a
> consensus system.
>
> Implementations of PoS sacrifice global consensus for 'weak
> subjectivity', meaning that each node has its own notion of when a
> certain block arrived. Astute observers will note that 'each node has
> its own notion of what happened' differs somewhat from 'all nodes agree
> on what happened', and that only one of these is a good description of
> what is commonly known as 'consensus'.
>
> Maybe a simpler way of looking at it is from the coder's perspective:
> how do you implement IBD? In PoW, the "longest chain" rule is used -
> "Nodes can leave and rejoin the network at will, accepting the
> proof-of-work chain as proof of what happened while they were gone.".
> Does PoS have this property?
>
> On 2021-06-24 21:50, Erik Aronesty wrote:
> >> PoS is not suitable for use as a consensus system, because
> > it is constitutionally incapable of producing a consensus.
> >
> > true - but only for a system that is starting from nothing.
> >
> > since bitcoin already exists, and we have a consensus, you can use
> > bitcoin's existing consensus to maintain that consensus using
> > references to prior state.  and yes, you simply have to limit reorgs
> > to not go back before PoW was abandoned in favor of PoS/PoB (assuming
> > all incentive problems are solved).
> >
> > ie: once you have uses PoW to bootstrap the system, you can "recycle"
> > that work.
> >
> > On Thu, Jun 24, 2021 at 4:41 PM yanmaani--- via bitcoin-dev
> > <bitcoin-dev@lists•linuxfoundation.org> wrote:
> >>
> >> No, 51% of the *coin holders* can't do diddly squat. 51% of miners
> >> can,
> >> but in PoW, that's a different set to the coin holders.
> >>
> >> The basic problem with PoS, anyway, is that it's not actually a
> >> consensus system ("weak subjectivity"). Either you allow long reorgs,
> >> and then you open the door to long-range attacks, or you don't, and
> >> then
> >> you're not guaranteed that all nodes agree on the state of the chain,
> >> which was the purpose of the system to begin with.
> >>
> >> To put it more plainly: for PoS to work, you need a consensus on which
> >> block was seen first. But if you had that, you could presumably apply
> >> that method to determine which *transaction* was seen first, in which
> >> case you could do away with the blockchain entirely. (Real-world
> >> implementations of PoS, such that they are, do away with this
> >> requirement, scrapping the global consensus on ordering in favor of
> >> having each node decide for itself which block came first.)
> >>
> >> In other words, even if you solved all the incentive problems, the
> >> fact
> >> remains that PoS is not suitable for use as a consensus system,
> >> because
> >> it is constitutionally incapable of producing a consensus.
> >>
> >> On 2021-06-24 00:14, Billy Tetrud via bitcoin-dev wrote:
> >> >>  This is not true in a Proof of Work system and this difference
> >> > absolutely should not be trivialized.
> >> >
> >> > That is in fact true of Proof of Work as well. If a colluding
> >> > coalition of miners with more than 50% of the hashrate want to censor
> >> > transactions, they absolutely can do that by orphaning blocks that
> >> > contain transactions they want to censor. This is not different in
> >> > proof of stake.
> >> >
> >> > On Wed, Jun 23, 2021 at 11:14 AM Keagan McClelland
> >> > <keagan.mcclelland@gmail•com> wrote:
> >> >
> >> >>> Premise: There is a healthy exchange market for PoS Coin X with
> >> >> tens of thousands of participants bidding to buy and sell the coin
> >> >> for other currencies on the market.
> >> >>
> >> >> The difference here though is that Proof of Stake allows the quorum
> >> >> of coin holders to block the exchange of said coins if they are
> >> >> going to a particular destination. Nothing requires these staking
> >> >> nodes to include particular transactions into a block. With that in
> >> >> mind, it isn't just that you require the permission of the person
> >> >> who sold you the coins, which I can agree is a less dangerous form
> >> >> of permission, but you must also require the permission of at least
> >> >> 51% of the coin holders to even receive those coins in the first
> >> >> place. This is not true in a Proof of Work system and this
> >> >> difference absolutely should not be trivialized.
> >> >>
> >> >> Keagan
> >> >>
> >> >> On Wed, Jun 23, 2021 at 2:30 AM Billy Tetrud via bitcoin-dev
> >> >> <bitcoin-dev@lists•linuxfoundation.org> wrote:
> >> >>
> >> >>> Barrier to entry in PoS is being given permission by the previous
> >> >> owner of a token
> >> >>
> >> >> The idea that proof of stake is not permissionless is completely
> >> >> invalid. It pains me to see such an argument here. Perhaps we can
> >> >> come to an agreement by being more specific. I'd like to propose the
> >> >> following:
> >> >>
> >> >> Premise: There is a healthy exchange market for PoS Coin X with tens
> >> >> of thousands of participants bidding to buy and sell the coin for
> >> >> other currencies on the market.
> >> >>
> >> >> If the premise above is true, then there is no significant
> >> >> permission needed to enter the market for minting blocks for PoS
> >> >> Coin X. If you make a bid on someone's coins and they don't like you
> >> >> and refuse, you can move on to any one of the other tens of
> >> >> thousands of people in that marketplace. Would you agree, Cloud
> >> >> Strife, that this situation couldn't be considered "permissioned"?
> >> >>
> >> >> If not, consider that participation in *any* decentralized system
> >> >> requires the permission of at least one user in that system. If
> >> >> there are thousands of bitcoin public nodes, you require the
> >> >> permission of at least one of them to participate in bitcoin. No one
> >> >> considers bitcoin "permissioned" because of this. Do you agree?
> >> >>
> >> >> On Thu, Jun 17, 2021 at 1:15 PM Cloud Strife via bitcoin-dev
> >> >> <bitcoin-dev@lists•linuxfoundation.org> wrote:
> >> >>
> >> >> Barrier to entry in PoW is matter for hardware and energy is
> >> >> permissionless and exist all over the universe, permissionless cost
> >> >> which exists for everyone no matter who because it's unforgeable.
> >> >>
> >> >> Barrier to entry in PoS is being given permission by the previous
> >> >> owner of a token for you to have it via transfer or sale, both
> >> >> choices they never have to make since there are no continuous costs
> >> >> with producing blocks forcing it. A permission is an infinitely high
> >> >> barrier to entry if the previous owner, like the premining party,
> >> >> refuses to give up the token they control.
> >> >>
> >> >> You're skipping the part where you depend on a permission of a
> >> >> central party in control of the authority token before you can
> >> >> produce blocks on your rasberry Pi.
> >> >>
> >> >> Proof of stake is not in any possible way relevant to permissionless
> >> >> protocols, and thus not possibly relevant to decentralized protocols
> >> >> where control must be distributed to independent (i.e.
> >> >> permissionless) parties.
> >> >>
> >> >> There's nothing of relevance to discuss and this has been figured
> >> >> out long long ago.
> >> >>
> >> >>
> >> >
> https://github.com/libbitcoin/libbitcoin-system/wiki/Proof-of-Stake-Fallacy
> >> >>
> >> >>
> >> >
> https://medium.com/@factchecker9000/nothing-is-worse-than-proof-of-stake-e70b12b988ca
> >> >>
> >> >> On Tue, Jun 15, 2021 at 7:13 AM James MacWhyte via bitcoin-dev
> >> >> <bitcoin-dev@lists•linuxfoundation.org> wrote:
> >> >>
> >> >> @Lloyd wrote:
> >> >>
> >> >> 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!
> >> >>
> >> >> I believe we are talking about a comparison to PoW, correct? If you
> >> >> want to mine PoW, you need to buy expensive hardware and configure
> >> >> it to work, and wait a long time to get any return by solo mining.
> >> >> Or you can join a mining pool, which might use your hashing power
> >> >> for nefarious purposes. Or you might skip the hardware all together
> >> >> and fall for some "cloud mining" scheme with a pretty website and a
> >> >> high rate of advertised return. So as you can see,
> >> >> Proof-of-SquareSpace exists in PoW as well!
> >> >>
> >> >> The PoS equivalent of buying mining hardware is setting up your own
> >> >> validator and not outsourcing that to anyone else. So both PoW and
> >> >> PoS have the professional/expert way of participating, and the
> >> >> fraud-prone, amateur way of participating. The only difference is,
> >> >> with PoS the professional/expert way is accessible to anyone with a
> >> >> raspberry Pi and a web connection, which is a much lower barrier to
> >> >> entry than PoW. _______________________________________________
> >> >> 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
> >> > _______________________________________________
> >> > 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
>
>
>

[-- Attachment #2: Type: text/html, Size: 17168 bytes --]