Hi all,

>>>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.

I think there is some misunderstanding here. A single node can be isolated from the rest of the network any time and when it reconnects it only has to follow the longest chain as always. Checking with a block-explorer or a friend's node is only required under the extreme situation of being under a 51% attack, but that is also a problem for Proof Of Work. Both protocols require manual intervention:

-PoS: Burn the funds of the attacker with a hard fork
-PoW: Change the PoW algorithm with a hard fork

The other extreme situation would be if the network or internet itself is splitted more than N blocks. If that happens, it should require manual intervention to merge both chains. But in PoW it's much worse because the longest chain wins and it erases all history of the losing chain. Are you sure that's better? All transactions of one day (or more) could be erased forever.

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

It's the same as above.

>>>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.

Yes but I think this can be solved in PoS, because there should be only 2 possible cases:

1 - The attacker doesn't stop making blocks in the main chain an he only censors transactions in his blocks: in this case, there is always some honest block so he can only slow the network
2 - The attacker does a 51% attack stopping doing blocks in the main chain, so the longest chain is his "private" chain which only has his blocks: then he can censor every transaction, but that attack is very evident and a hard fork could burn his funds.

>>> Aside from that, this is possible to evade by running 10000 masternodes and splitting your staking funds among them.

It's possible to give more staking weight to coins together in a single address than splitted coins like with this formula (or some improved version)

stakingWeight = numberOfCoins ^ 1000

So imagine Bitcoin has only 100 coins in 2 wallets, the honest wallet has 2 coins in a single address, and the attacker wallet splits his 98 coins in 98 addresses:

honestValidatorStakingWeight = 2 ^ 1000 = Very big number

attackerStakingWeightPerAddress = 1 ^ 1000 = 1
totalAttackerWeight = 1 * 98 = 98

So X coins together always have more weight than any bigger amount of coins splitted in amounts smaller than X. The attacker needs to have at least one address with X coins.

>>> Basically: "never base consensus rules on mempool state" is a good rule of thumb for ensuring that consensus can be maintained.

Yep it's only an idea, if a big number of transactions is being censored it should be possible to detect it. After some time an increasing number of nodes will see that they have very old transactions in their mempools even if blocks are not full.

>>> 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.

Do you think Ethereum PoS will fail?

Regards,


From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Sent: Thursday, July 18, 2019 3:13
To: Eric Voskuil
Cc: Kenshiro []; Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] Secure Proof Of Stake implementation on Bitcoin
 
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