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 <zmnsc...@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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
