Date: Thu, 18 Jul 2019 01:13:27 +0000
To: Eric Voskuil <eric@voskuil.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <brBQhROvRWwcPjdOBU0_7e0_dpBN4Noy1gP9TaEB6bEiOWTa3Huumz242_pjVI27u_G_edcTX7Ko6aD6pi6ta1vdQMzHCAli5Q_-55HD2SU=@protonmail.com>
In-Reply-To: <207DBF48-E996-440D-ADDC-3AEC9238C034@voskuil.org>
References: <DB6PR10MB183264613ED0D61F2FBC6524A6F30@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>
	<Hyx4PP6c5-kzdKTCrIQLO1W3Hve-bm5gDiY5pBq8wi6ry2J-1KPO4TDJrRxk7rwq-3aEIUIkkYdKqmPwTzlQZBU-3xUf-fru_drJ9PM4yRI=@protonmail.com>
	<DB6PR10MB1832BAAB9D194B6AA61C2573A6C90@DB6PR10MB1832.EURPRD10.PROD.OUTLOOK.COM>
	<207DBF48-E996-440D-ADDC-3AEC9238C034@voskuil.org>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
	"Kenshiro \[\]" <tensiam@hotmail.com>
Subject: Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin
Precedence: list

Good morning all,

> > >>>Under the trust-minimization requirement of Bitcoin this is simply n=
ot acceptable.
> > As there is no way to trust-minimally heal from a network split (and ev=
ery time a node is shut down, that is indistinguishable from a network spli=
t that isolates that particular node), this is not a trust-minimizing conse=
nsus algorithm.
>
> That=E2=80=99s nonsense, one is a feature (systemic trust), the other is =
a bug (code accident). But there is a way to minimize actual forks - try no=
t to change the consensus rules in the code you ship.

I am uncertain what you mean here.

What I am attempting to compare are:

1.  A network split (maybe better term is "network partition"?) wherein som=
e number of nodes are temporarily unable to contact the rest of the network=
.
    This has the degenerate but very common case where a single node is tem=
porarily unable to communicate with the rest of the network.

AND

2.  A node being shut down, then brought back online again.

Neither seems to match "feature" or "bug", as both are simply accidents of =
deployment.

The point (as I understand it) of a consensus algorithm is to be able to ge=
t all nodes into agreement about the global state, even after a network par=
tition.
Ideally, such an algorithm would place as little trust as possible on some =
other node, and would work even in adversarial conditions.

To my understanding, the proposal from Kenshiro is not able to get all node=
s into agreement about global state after a network partition, without trus=
t in some node, when in adversarial conditions.


> > >>> History rewrites are not the only attack possible.
> > The worst attack is a censorship attack, and a 99% staker can easily ce=
nsor on the creation of new blocks.
> >
> > I don't agree, history rewrite attacks are much worse than censorship b=
ecause they can be used to steal funds from people.
>
> Censorship can steal everybody=E2=80=99s money.

To expand on this: by censoring ***all*** transactions one is able to preve=
nt spending of all funds.
This will crash the value of the staked funds also, but note that the stake=
r could use techniques like short options to leverage this and potentially =
earn more than the value of their staked funds, effectively stealing the en=
tire marketcap of the attacked coin.


>
> > In PoS staking addresses are public, so maybe it should be possible to =
detect if some transaction in the mempool is repeatedly=C2=A0being ignored =
and what staking deposit is repeatedly ignoring transactions. After some ti=
me, a hard fork could burn the funds of the evil validator.
>
> Political money.

Aside from that, this is possible to evade by running 10000 masternodes and=
 splitting your staking funds among them.
Rent from a botnet, and it appears the masternodes are geographically diver=
se.
Then it becomes hard to accuse the network of actually being controlled str=
ongly by a single participant.
(the ability to rent botnets means that even existing PoS coins might alrea=
dy be strongly controlled, but appear "healthy" because masternodes *appear=
* geographically diverse, but in actuality are controlled by a single entit=
y)

Further, "detect if some transaction in the mempool" cannot provide a proof=
, as no construct ever precommits to the state of the mempool at a particul=
ar time (if it did, the mempool would cease to be a mempool and would be pa=
rt of the block).
I can generate a completely new transaction, then accuse the masternodes of=
 censoring it.
Other nodes may not believe me, as they have not seen my transaction on the=
ir mempool, but note that the mempools of nodes are ***not*** strongly sync=
hronized.
By careful timing and control of the connectivity of the network, it become=
s possible to effectively split the consensus algorithm by showing my trans=
action to some non-masternode nodes but keeping my transaction away from ma=
sternodes, then have the non-masternode nodes accuse the masternodes of cen=
soring my transaction and hereby penalizing them.
But the masternodes would not agree, not having seen my transaction in thei=
r mempool, and thus is the network consensus destroyed.

Basically: "never base consensus rules on mempool state" is a good rule of =
thumb for ensuring that consensus can be maintained.
Consensus rules should consider only data that is committed to some block, =
and the mempool is not intended to be committed to in every block.


> > https://www.coingecko.com/en/coins/nxt
> >
> > Another thing is that Ethereum itself is going to PoS next year, but wi=
th a different implementation that I'm proposing here.
>
> Just another nail in the coffin.

I agree.


Regards,
ZmnSCPxj