Subject: Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin

From: ZmnSCPxj <[email-masked]>
Date: Thu, 18 Jul 2019 01:13:27 +0000

Good morning all,

> > >>>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.
>
> That’s nonsense, one is a feature (systemic trust), the other is a bug (code accident). But there is a way to minimize actual forks - try not 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 some 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 temporarily 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 get all nodes into agreement about the global state, even after a network partition.
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 nodes into agreement about global state after a network partition, without trust 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 censor on the creation of new blocks.
> >
> > I don't agree, history rewrite attacks are much worse than censorship because they can be used to steal funds from people.
>
> Censorship can steal everybody’s money.

To expand on this: by censoring ***all*** transactions one is able to prevent spending of all funds.
This will crash the value of the staked funds also, but note that the staker could use techniques like short options to leverage this and potentially earn more than the value of their staked funds, effectively stealing the entire 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 being ignored and what staking deposit is repeatedly ignoring transactions. After some time, 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 diverse.
Then it becomes hard to accuse the network of actually being controlled strongly by a single participant.
(the ability to rent botnets means that even existing PoS coins might already be strongly controlled, but appear "healthy" because masternodes *appear* geographically diverse, but in actuality are controlled by a single entity)

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 particular time (if it did, the mempool would cease to be a mempool and would be part 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 their mempool, but note that the mempools of nodes are ***not*** strongly synchronized.
By careful timing and control of the connectivity of the network, it becomes possible to effectively split the consensus algorithm by showing my transaction to some non-masternode nodes but keeping my transaction away from masternodes, then have the non-masternode nodes accuse the masternodes of censoring my transaction and hereby penalizing them.
But the masternodes would not agree, not having seen my transaction in their 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 with a different implementation that I'm proposing here.
>
> Just another nail in the coffin.

I agree.

Regards,
ZmnSCPxj