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

From: Billy Tetrud <billy.tetrud@gmail•com>
To: Lloyd Fournier <lloyd.fourn@gmail•com>
Cc: Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>,
	SatoshiSingh <SatoshiSingh@protonmail•com>
Subject: Re: [bitcoin-dev] Opinion on proof of stake in future
Date: Sun, 23 May 2021 09:28:43 -1000	[thread overview]
Message-ID: <CAGpPWDbfZeAMpH6h05nAnxL=2dpNB9E7BJef8eNriQgGctMmaQ@mail.gmail.com> (raw)
In-Reply-To: <CAGpPWDaBZ3Zx9VnSt01Rs5G9z1RsZgez+dF4P=PCP=jYN8M1Xg@mail.gmail.com>

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

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 *pools
could..."

On Sun, May 23, 2021 at 9:10 AM Billy Tetrud <billy.tetrud@gmail•com> wrote:

> @Lloyd
>
> >  Proof-of-SquareSpace
>
> I agree with your points about delegated proof of stake. I wrote my own
> critique about that
> <https://github.com/fresheneesz/quantificationOfConsensusProtocolSecurity#analysis-of-delegated-proof-of-stake-dpos> as
> well. And your point, that other forms of PoS devolve to DPoS by virtue of
> people wanting to actively mint blocks without exposing their coins in hot
> 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 of
> 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 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.
>
> > 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 their
> 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 bit
> border line. With 1 billion people attempting to participate and 10 minute
> blocks, 232 people would need to share the block reward in order to expect
> 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 cosigner
> 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. Great
> 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, that
> 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 section
> from my above link, this might satisfy your curiosity
> <https://github.com/fresheneesz/ValidatedProofOfStake>.
>
> 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
>> 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 underlying
>> 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 largest
>> 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 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.
>> 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 you gain a dishonest majority and start
>> 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 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 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 lose
>> 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 keys
>> 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 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
>> 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 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
>> 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 success
>>> 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 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 critical security properties
>>> bitcoin relies on. I think the critical piece of this is the disagreements
>>> 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) affect
>>> 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 considered
>>> whether what happens in the case of a 51% may not be significantly
>>> different. The currency would likely be critically damaged in a 51% attack
>>> 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 the
>>> centralization pressure 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 tendency towards oligopolistic control is worse for PoW.
>>>
>>> > Energy usage, in-and-of-itself, is nothing to be ashamed of!!
>>>
>>> I certainly agree. Bitcoin's energy usage at the moment is I think quite
>>> warranted. However, the question is: can we do substantially better. I
>>> think if we can, we probably should... eventually.
>>>
>>> > Proof of Stake is only resilient to ⅓ of the network demonstrating a
>>> Byzantine Fault, whilst Proof of Work is resilient up to the ½ threshold
>>>
>>> I see no mention of this in the pos.pdf
>>> <https://download.wpsoftware.net/bitcoin/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 have a collective 100 exahashes/s hashpower, an
>>> attacker does not need to obtain 100 exahashes/s, but actually only needs
>>> to accumulate 50 exahashes/s. This is because as the attacker accumulates
>>> hashpower, it drives honest miners out of the market as the difficulty
>>> increases to beyond what is economically sustainable. Also, its 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
>>> <https://github.com/fresheneesz/quantificationOfConsensusProtocolSecurity#the-selfish-economic-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) — 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
>>> 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 of
>>> 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 agreed
>>> 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 <mike@powx•org>
>>>> 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 other
>>>>> threads going on these topics already where they would be relevant.
>>>>>
>>>>> Also, it's important to distinguish between oPoW and these other
>>>>> "alternatives" to Hashcash. oPoW is a true Proof of Work that doesn't 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, 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.  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, but 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
>>>>>> 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; they are
>>>>>> inherently 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
>>>>>> 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 <http://www.powx.org/>
>>>>>
>>>>
>>>>
>>>> --
>>>> Michael Dubrovsky
>>>> Founder; PoWx
>>>> www.PoWx.org <http://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
>>>
>>

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