> On Jul 17, 2019, at 03:10, Kenshiro [] via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> wrote: > > Hi ZmnSCPxj, > > I'm based on the more evolved implementation of PoS that I know, which is PoS > v3.0 and it's currently implemented in several coins: > > http://earlz.net/view/2017/07/27/1904/the-missing-explanation-of-proof-of-stake-version > > As far as I know the grinding attack is and old issue that is fixed in PoS > v3.0. > > >>>At least the proposed `assumeutxo` requires the operator to explicitly > >>>enable it, but I believe your "hardcoded checkpoints" cannot be disabled, > >>>much less disabled-by-default. > > We don't trust the developers, the source code is public and anyone can check > it. With the hardcoded checkpoints is exactly the same, they are in the > source code repository and everyone can check them. The checkpoints are the > easiest part to check. A user doesn't have any reason to remove the > checkpoints, but as with anything in the source code, they could modify it to > avoid the checkpoints (and become vulnerable to Long Range attacks doing it)
Bad precedent set by Bitcoin, just like retroactively hardcoding soft fork activation checkpoints. > >>>Under the trust-minimization requirement of Bitcoin this is simply not > >>>acceptable. > As there is no way to trust-minimally heal from a network split (and every > time a node is shut down, that is indistinguishable from a network split that > isolates that particular node), this is not a trust-minimizing consensus > algorithm. That’s nonsense, one is a feature (systemic trust), the other is a bug (code accident). But there is a way to minimize actual forks - try not to change the consensus rules in the code you ship. > The block explorer or other additional source of trust like a friend would > only be required in the extreme situation that the network is under a 51% > attack, and only by the nodes that are updating blocks in that moment. > Updated nodes are fully protected, and under normal circumstances new nodes > can just follow the longest chain as always. The other extreme situation that > could cause a hard fork is that the network is splitted more than N blocks, > which should require some social consensus to fix it. So N should be long > enough, like a few hours of blocks or even 1 day. Consensus rules are the social consensus. If you have an objective way to do this, write the rule. > >>> History rewrites are not the only attack possible. > The worst attack is a censorship attack, and a 99% staker can easily censor > on the creation of new blocks. > > I don't agree, history rewrite attacks are much worse than censorship because > they can be used to steal funds from people. Censorship can steal everybody’s money. > In PoS staking addresses are public, so maybe it should be possible to detect > if some transaction in the mempool is repeatedly being ignored and what > staking deposit is repeatedly ignoring transactions. After some time, a hard > fork could burn the funds of the evil validator. Political money. > >>> Worse, under proof-of-stake it is often the case that stakers are awarded > >>> even more coin with which they can stake. > > Sure, but in PoW the miners with more hash power earn more coins that can be > used to purchase more miners. True, but this is at least limited proportionally. > There is always the privilege of the rich guy, no matter if its PoW or PoS. > The point is to design a protocol that don't allow the rich to destroy the > network. The ability to introduce new power to the chain is the only way to evict a censor. In PoS a well capitalized individual or state can buy total control over the system forever at no ongoing cost. PoW allows any number of individuals to pay higher fees on censored txs and evict the censor, who must then maintain the cost of subsidizing censorship. > Let me put it in this way: NXT is a PoS coin that uses moving checkpoints > with a market cap of 21 million dollars. If the current PoS protocols are so > flawed, how can you explain that a coin with this market cap is not being > attacked? The state doesn’t care because there is no material impact from it? It hasn’t started attacking Bitcoin yet either. > https://www.coingecko.com/en/coins/nxt > > Another thing is that Ethereum itself is going to PoS next year, but with a > different implementation that I'm proposing here. Just another nail in the coffin. Best, Eric > Regards, > > > From: ZmnSCPxj <zmnsc...@protonmail.com> > Sent: Wednesday, July 17, 2019 1:00 > To: Kenshiro \[\]; Bitcoin Protocol Discussion > Subject: Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin > > Good morning Kenshiro, > > > Sent with ProtonMail Secure Email. > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Tuesday, July 16, 2019 8:33 PM, Kenshiro \[\] via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> wrote: > > > Hi, > > > > After studying several Proof of Stake implementations I think it's not only > > an eco-friendly (and more ethical) alternative to Proof of Work, but > > correctly implemented could be 100% secure against all 51% history rewrite > > attacks. Over a "standard" PoS protocol like PoS v3.0, only 2 extra > > improvements are required: > > Under the trust-minimization and uncensorability requirements that Bitcoin > has, nothing is more efficient than proof-of-work. > The very idea of proof-of-stake labors under the assumption that unencumbered > free-market payment for the consumption of energy is somehow not > market-efficient despite the well-known phenomenon of the invisible hand, and > believes that it is possible to get something for nothing. > > Please re-examine your assumptions. > > > - Hardcoded checkpoints:each Bitcoin Core release (each few months) should > > include a hardcoded checkpoint with the hash of the current block height in > > that moment. This simple measure protects the blockchain up to the last > > checkpoint, and prevents any Long-Range attack. > > While this is a developer list and made up of developers who would be quite > incentivized to agree to such a setup, note that this effectively trusts the > developers. > At least the proposed `assumeutxo` requires the operator to explicitly enable > it, but I believe your "hardcoded checkpoints" cannot be disabled, much less > disabled-by-default. > > > This extra rule could be connecting to a block explorer to download the > > hash of the current block height, or ask some trusted source like a friend > > and enter the hash manually. After being fully updated, the user can always > > check that he is in the correct chain checking with a block explorer. > > Under the trust-minimization requirement of Bitcoin this is simply not > acceptable. > As there is no way to trust-minimally heal from a network split (and every > time a node is shut down, that is indistinguishable from a network split that > isolates that particular node), this is not a trust-minimizing consensus > algorithm. > > > > > Someone could have 99% of the coins and still would be unable to use the > > coins to do any history rewrite attack. The attacker could only slow down > > the network not creating his blocks, or censor transactions in his blocks. > > History rewrites are not the only attack possible. > The worst attack is a censorship attack, and a 99% staker can easily censor > on the creation of new blocks. > > Censorship attacks cannot be prevented except by ensuring that no single > entity can claim 51% control of new block creation. > By ensuring this, we can ensure that at least some other entities are > unlikely to keep a transaction out of the blockchain, and in particular that > no entity can make a short-ranged history rewrite if a censored transaction > *does* get into the blockchain from the efforts of another block producer. > > This is trivial under proof-of-work, and is the cost we accept in order to > achieve uncensorability, since it is non-trivial to acquire energy. > Under proof-of-stake it is difficult to impossible to determine if some > single entity controls >51% of stakeable coins, and thus has no way to > protect against censorship attack. > Worse, under proof-of-stake it is often the case that stakers are awarded > even more coin with which they can stake. > > Depending on the PoS implementation, stake-grinding may allow a 49% staker to > achieve 51% and thereby the ability to censor transactions. > > > Regards, > ZmnSCPxj > _______________________________________________ > 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
