Date: Tue, 16 Jul 2019 23:00:02 +0000
To: "Kenshiro \\[\\]" <tensiam@hotmail.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <Hyx4PP6c5-kzdKTCrIQLO1W3Hve-bm5gDiY5pBq8wi6ry2J-1KPO4TDJrRxk7rwq-3aEIUIkkYdKqmPwTzlQZBU-3xUf-fru_drJ9PM4yRI=@protonmail.com>
In-Reply-To: <DB6PR10MB183264613ED0D61F2FBC6524A6F30@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>
References: <DB6PR10MB183264613ED0D61F2FBC6524A6F30@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin
Precedence: list

Good morning Kenshiro,


Sent with ProtonMail Secure Email.

=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
On Tuesday, July 16, 2019 8:33 PM, Kenshiro \[\] via bitcoin-dev <bitcoin-d=
ev@lists.linuxfoundation.org> wrote:

> Hi,
>
> After studying several Proof of Stake implementations I think it's not on=
ly an eco-friendly (and more ethical) alternative to Proof of Work, but cor=
rectly implemented could be 100% secure against all 51% history rewrite att=
acks. Over a "standard" PoS protocol like PoS v3.0, only 2 extra improvemen=
ts 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 unencumber=
ed free-market payment for the consumption of energy is somehow not market-=
efficient despite the well-known phenomenon of the invisible hand, and beli=
eves that it is possible to get something for nothing.

Please re-examine your assumptions.

> - Hardcoded checkpoints:each Bitcoin Core release (each few months) shoul=
d 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 t=
he developers.
At least the proposed `assumeutxo` requires the operator to explicitly enab=
le 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 h=
ash of the current block height, or ask some trusted source like a friend a=
nd 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 acce=
ptable.
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 th=
at 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 t=
he 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 en=
tity can claim 51% control of new block creation.
By ensuring this, we can ensure that at least some other entities are unlik=
ely 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 *d=
oes* 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 sin=
gle 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 e=
ven 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