rich1.0npub1xqcwcttsyk0a64d63crrwsxp88pa42np37rw87hrfn4uku78g2aqltcnnshttps://nostr.ae/npub1xqcwcttsyk0a64d63crrwsxp88pa42np37rw87hrfn4uku78g2aqltcnnsnjumphttps://nostr.ae📅 Original date posted:2021-05-23 📝 Original message: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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at lists.linuxfoundation.org >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>>> >>> _______________________________________________ >>> bitcoin-dev mailing list >>> bitcoin-dev at lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210523/16cfd723/attachment-0001.html>