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
