From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: "Kenshiro \\[\\]" <tensiam@hotmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin
Date: Tue, 16 Jul 2019 23:00:02 +0000 [thread overview]
Message-ID: <Hyx4PP6c5-kzdKTCrIQLO1W3Hve-bm5gDiY5pBq8wi6ry2J-1KPO4TDJrRxk7rwq-3aEIUIkkYdKqmPwTzlQZBU-3xUf-fru_drJ9PM4yRI=@protonmail.com> (raw)
In-Reply-To: <DB6PR10MB183264613ED0D61F2FBC6524A6F30@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>
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
next prev parent reply other threads:[~2019-07-16 23:00 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-11 15:16 Kenshiro []
2019-07-16 20:35 ` Oscar Lafarga
2019-07-16 21:28 ` Kenshiro []
2019-07-17 8:11 ` ZmnSCPxj
2019-07-16 23:00 ` ZmnSCPxj [this message]
2019-07-17 10:10 ` Kenshiro []
2019-07-17 12:02 ` Eric Voskuil
2019-07-18 1:13 ` ZmnSCPxj
2019-07-18 9:58 ` Kenshiro []
2019-07-18 14:15 ` ZmnSCPxj
2019-07-18 15:50 ` Kenshiro []
2019-07-19 3:45 ` ZmnSCPxj
2019-07-19 5:10 ` Eric Voskuil
2019-07-19 10:24 ` Kenshiro []
2019-07-19 9:48 ` Kenshiro []
2019-07-20 0:45 ` ZmnSCPxj
2019-07-20 10:37 ` Kenshiro []
2019-07-20 11:07 ` ZmnSCPxj
2019-07-20 13:00 ` Kenshiro []
2019-07-24 4:14 ` ZmnSCPxj
2019-07-24 9:30 ` Kenshiro []
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='Hyx4PP6c5-kzdKTCrIQLO1W3Hve-bm5gDiY5pBq8wi6ry2J-1KPO4TDJrRxk7rwq-3aEIUIkkYdKqmPwTzlQZBU-3xUf-fru_drJ9PM4yRI=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=tensiam@hotmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox