path: root/22/9fcab6368b0eb749f04b499ea8899a61ebef54

Return-Path: <yanmaani@cock.li>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 1CB13C000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 25 Jun 2021 00:29:33 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id EA935401B7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 25 Jun 2021 00:29:32 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: 1.233
X-Spam-Level: *
X-Spam-Status: No, score=1.233 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, RCVD_IN_PBL=3.335,
 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=cock.li
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id F58-5EleknvW
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 25 Jun 2021 00:29:28 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from mail.cock.li (mail.cock.li [37.120.193.124])
 by smtp2.osuosl.org (Postfix) with ESMTPS id ECEF7400C3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 25 Jun 2021 00:29:27 +0000 (UTC)
MIME-Version: 1.0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cock.li; s=mail;
 t=1624580959; bh=c6dfjuIXMPRUIH58Zm3z6ZgYFCyEc6ur0EwjeT6ZBjo=;
 h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
 b=zQJw0xazdOxK2+hWAdqp8JtH3BxmFK5z/OdzYD2W7mMXmRifB10uqGLuzt7TmVwCD
 y7uGU1DlhE2eZKGoKN2x0lhZnKlmG16V/q+eM8vjTp4TTQupzCPZ+5gZZvSfrIm9qb
 Zib2w81TWBI/JZoJMQLJF276Kp+D2/KGX7jkhPnECYQBZqU4aTYUFj1LpxkMznGL7+
 r0EJVLZ/QEltjUqMmA/0QqXQnY/VvWsds27SNT4qVNAmqTuFDpg0kXSO+W9Rpy6MJt
 R+PIQ5O/KUEttnaRvr8n1GKPtrf7AQu2YDOWiSPvqkWqAB/Yu+Lpxh0JEKZ3X3EIQl
 GXF4tVVoNc0IA==
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Fri, 25 Jun 2021 00:29:19 +0000
From: yanmaani@cock.li
To: Erik Aronesty <erik@q32.com>
In-Reply-To: <CAJowKgLonaN_=Zyn6R7QDpQHPHKP+8D6xJyD9Z_c68auZx8Abg@mail.gmail.com>
References: <6do5xN2g5LPnFeM55iJ-4C4MyXOu_KeXxy68Xt4dJQMhi3LJ8ZrLICmEUlh8JGfDmsDG12m1JDAh0e0huwK_MlyKpdfn22ru3zsm7lYLfBo=@protonmail.com>
 <CAJowKg+QM94g+JcC-E-NGD4J9-nXHWt5kBw14bXTAWaqZz=bYw@mail.gmail.com>
 <CALeFGL02d9NVp+yobrtc2g6k2nBjBj0Qb==3Ukkbi8C_zb5qMg@mail.gmail.com>
 <CAD5xwhi1G3Jj3FAAWQP3BXTK34ugDQY32hq-cQnt8Ny8JP4eGQ@mail.gmail.com>
 <CAJowKgJ1x5YKWS1S-sgdU3Tn+hPT64iiUCwG8qh-JS0xqS7ieA@mail.gmail.com>
 <30li5MRxkBhzLxLmzRnHkCdn8n3Feqegi-FLZ5VDyIX2uRJfq4kVtrsLxw6dUtsM1atYV25IfIfDaQp4s2Dn2vc8LvYkhbAsn0v_Fwjerpw=@protonmail.com>
 <CAJ4-pEBYJNuNMUCt5J5DbKU4RC9JXcO7gZdKh2Vq6PHCmddaeg@mail.gmail.com>
 <hASF-iYeGlsq3EhNWY0EWhk5S8R1Wwn534cWsrwLInd8K7f7bUDCAP4GgTj8_ZNsKtgv8y09GJovcS6KXhYRHODC5N_88fvCAF1Z-r2TUFg=@protonmail.com>
 <CAJ4-pECb9QSUDPax8SU+-KGwPgVju=YKax9eb-iRwAmZGcMcPg@mail.gmail.com>
 <CAJowKgJ3DOrtO+_XzoEnqQUQdge=zCopg2mvuy5F=RSeaVPJYQ@mail.gmail.com>
 <CAKy8i-17Snk7ZeTL_U8ULDm3S5fYRXf412p1NpS_6CTT4Fhm0A@mail.gmail.com>
 <CAKy8i-0efmC_AmAK6oLy1FooXd6WeSeOvRUOJ8Lb6BJoqduDTQ@mail.gmail.com>
 <CAGpPWDaiGdgrECZzvM67O6t-kVieL4uR4ydEkHr+gwUB7Ahykg@mail.gmail.com>
 <CAH5Bsr2WaOhSObNX-=61md6tF49auaH7wUB08qKv5baiFutxSw@mail.gmail.com>
 <CAH+Axy7mc9pRfnQwmPx5BE8z9R3gGA2FtJkBEcbprKSgW0M6zg@mail.gmail.com>
 <CAHeORg+b=2j9zTFeWEmxWBBQ584oSXpN6t0ujnvbAteWLSbJ3Q@mail.gmail.com>
 <CAGpPWDZjsiHgN2_nzgpwF-Pq8btdbPQm3=f06S8nNfpSp+_GHw@mail.gmail.com>
 <CALeFGL3GZZy8J3VKbuQjof_c7nbGTCd-eY3_h3mH=mZnKehLMw@mail.gmail.com>
 <CAGpPWDb2MwcFFXtvOhr6WC3aUK5yfYUyJKbxDeLYHqbzYU7i7w@mail.gmail.com>
 <b6e297d7d6c1ce386beb5c45e348f1a1@cock.li>
 <CAJowKgLonaN_=Zyn6R7QDpQHPHKP+8D6xJyD9Z_c68auZx8Abg@mail.gmail.com>
Message-ID: <f4ae76d8c055689ae0ca68a14fb5e612@cock.li>
X-Sender: yanmaani@cock.li
User-Agent: Roundcube Webmail/1.3.15
X-Mailman-Approved-At: Fri, 25 Jun 2021 07:29:02 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Billy Tetrud <billy.tetrud@gmail.com>
Subject: Re: [bitcoin-dev] Opinion on proof of stake in future
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Jun 2021 00:29:33 -0000

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