ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2019-07-16 📝 Original message:Good morning Kenshiro, ...

📅 Original date posted:2019-07-16
📝 Original message:Good morning Kenshiro,


Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, July 16, 2019 8:33 PM, Kenshiro \[\] via bitcoin-dev <bitcoin-dev at 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