Except you won't because you'll have to wait so long to be able to use the old coins that you'll miss the window of opportunity. Also, it doesn't matter because you need > 50% of the actively minting coins in order to succeed anyway. And if you had that, you don't need to worry about being slashed at all.
What "window of opportunity"? Ostensibly these coins will remain valuable far into the future, and therefore the ability to spend them twice will also remain valuable.
> Also, it doesn't matter because you need > 50% of the actively minting coins in order to succeed anyway.
If you have the ability to mint blocks, you can use include signed transactions from the real chain to unstake and build majority on nodes you control.
I would discourage you from responding on this topic until you've read the first paper I linked, as you have not said anything that wasn't addressed in that paper.
The window of opportunity to use your old keys (with old coins) to create a malicious chain.
> If you have the ability to mint blocks, you can use include signed transactions from the real chain to unstake and build majority on nodes you control.
If the attacker is building their own chain, no one else will be building on top of it. Anyone will see that the chain has very few coins actively minting and will be immediately suspect, even if they're eclipsed. If they're not eclipsed, they'll go with the honest chain, which would be clearly longer unless this was a 51% attack situation.
>I would discourage you from responding on this topic
If you're going to be rude, I'm just going to ignore you. Its pretty insulting to tell me that. I've written two different consensus protocols, and analysed the security properties of many more. I very much doubt you've put anywhere near as much work into understanding the attacks and solutions around consensus protocols. So please don't be pompous.
When there is a network split, nodes on one side of the split might think they have the longest chain and be wrong about it. Unless you know you have most of the computing power on your side of the network split, you can't really know which side has the longest chain until the network split is over.
So no, Bitcoin doesn't avoid the need to achieve consensus.
What I actually said is, "[I]f you're only connected to two nodes and those two nodes are showing you two different spends of the same balance, you have no way to resolve that conflict. In PoW (a real proof algorithm) you simply look at the longer chain."
You're correct that this isn't a proof of consensus.
Maybe that's assumed in "simply look at the longer chain" but I thought I'd point it out.
It's silly to say PoS doesn't work when what you really mean is that some badly designed PoS systems don't work. Slashing is a solution to a problem. It's honestly irrelevant if some PoS systems don't do slashing.
From peercoin (first pos coin) whitepaper: "Roughly speaking, proof-of-stake means a form of proof of ownership of the currency."
> But if you're only connected to two nodes and those two nodes are showing you two different spends of the same balance, you have no way to resolve that conflict. In PoW (a real proof algorithm) you simply look at the longer chain.
From the same whitepaper: "The protocol for determining which competing block chain wins as main chain has been switched over to use consumed coin age. Here every transaction in a block contributes its consumed coin age to the score of the block. The block chain with highest total consumed coin age is chosen as main chain."
I mean, looking at it it seems that your main complaints were actually addressed some 9 years ago in the first PoS whitepaper.
Just because a whitepaper says something doesn't mean it's has held up to peer review.
> From the same whitepaper: "The protocol for determining which competing block chain wins as main chain has been switched over to use consumed coin age. Here every transaction in a block contributes its consumed coin age to the score of the block. The block chain with highest total consumed coin age is chosen as main chain."
Consumed coin age is not provable by looking at the chain--it's only provable by polling the network for consensus.
> I mean, looking at it it seems that your main complaints were actually addressed some 9 years ago in the first PoS whitepaper.
I mean, looking at it it seems you didn't read the first paper I linked, or indeed much of the literature on proof of stake which has been written in the last 9 years.
Lol, you're a genius! Bwahahaha!
First, you're describing a very particular implementation of PoS. Not all PoS implementations include slashing. This isn't a mere technicality: the most popular implementation of PoS (as measured by market cap) is Cardano's and it doesn't include slashing. And not all PoS implementations involve randomly choosing a validator.
The bigger problem here is that proof of stake is actually a misnomer because doesn't actually provide proof, period--it's a consensus algorithm, not a proof algorithm. That's fine if you're actively connected to a bunch of nodes, because you can resolve double spends by polling the network to find out the consensus. But if you're only connected to two nodes and those two nodes are showing you two different spends of the same balance, you have no way to resolve that conflict. In PoW (a real proof algorithm) you simply look at the longer chain. In PoS, there's no way to actually enforce the longer chain, because there's no cost to producing a longer chain. This is a problem which occurs in practice when nodes newly connect to a network or reconnect after a long absence.
Slashing does nothing to address this issue. If I'm running a PoS validator node, I can stake coins, unstake them, and then spend the coins. Now I've got a free license to mine blocks without risk of slashing. I can mine blocks by simply validating blocks that say that I never unstaked. And I'm at no risk of slashing because I've already spent the coins: there's no balance to slash.
You alluded to an attempted solution with "it is solved by randomly choosing which validator will create the next block according to an algorithm that all the nodes follow" but that doesn't work: a provable random function can choose a validator which creates artificial scarcity, but there has to be a fallback in case validators drop offline, otherwise a downed node would grind the entire chain to a halt as soon as it was chosen as a validator and doesn't validate a block when it's supposed to. The malicious validator can use this because there's no temporality stored on-chain: you just find a situation where your staking address is the fallback node and claim that the validators who were chosen by the random function validated late, and nobody can prove you wrong. This may sound suspicious, but in fact these fallbacks happen in practice. To create a believable chain after this, you have to create a situation where a lot of validators drop off and are replaced by nodes you control. This also looks suspicious, but again this also happens in practice: for example if AWS S3 US East VA goes down, there will be a huge number of validators that drop offline.
Probably the most thorough explanation of this type of attack and the theory behind it can be found in On Stake and Consensus[1].
There's some debate on the importance of this attack--Vitalik Buterin calls this "weak subjectivity" and has written about it in length[2]. But to say he's not concerned about it would be inaccurate; he says, "actually implementing a proof of stake algorithm that is effective is proving to be surprisingly complex"[3]. That sentence was written in 2014 and Ethereum still does not rely on proof of stake in 2021--be assured that if in seven years Vitalik Buterin has not satisfactorily solved the problem, it's not trivial. I would caution anyone extolling the virtues of Proof of Stake from overstating their case--PoS is not a panacea and presents many challenges of its own.
[1] https://download.wpsoftware.net/bitcoin/pos.pdf
[2] https://blog.ethereum.org/2014/11/25/proof-stake-learned-lov...
[3] https://blog.ethereum.org/2014/10/03/slasher-ghost-developme...