"slashing" does nothing to address the fundamental problem. It leaves you with the same circular dependency.
Step 1. Acquire crypto currency. Step 2. Stake. Step 3. unstake and sell cryptocurrency. Step 4. use older keys to produce an alternative history.
Or, to simplify things, let other people do 1/2/3. Then purchase or hack their now-worthless old used keys to use in your attack... keys which they have no reason to protect and/or not sell. At most, all slashing does is makes Step 3 take more time.
I say "at most" because it doesn't necessarily do that much: if the funds you can earn from the attack (from double-spends and/or shorts) are large compared to the staked amounts, then step 3 isn't even required.
POS is fundamentally circular: you use ownership to determine ownership.
The only solution to this is to introduce another consensus mechanism like POW or, more commonly in POS proposals, a centralized authority. Some just assume the users are communicating over a synchronous lossless global totally ordered reliable broadcast-- which, again, is equivalent to running on top of another consensus system.
There is a reason you see people promoting POS that have an established history of committing fraud: the idea is most convincing if you obfscuate the details so much that no one is going to be willing to waste their time reviewing it. This is one of the classic moves used to convince someone to agree to a fradulent deal-- baffle 'em with bullshit.
You misunderstand some of the nuances of PoS that make it secure. Along with slashing, there is a period of time during which your staked funds are frozen, where they are unspendable and unsellable. This period is supposed to be long enough such that all nodes sync at least once during that period (think on the order of weeks or months). So if you try to create an alternative history during that period, your funds are slashed (since you couldn't have sold them). And if you try to create an alternative history after that period, everyone will know you're lying, since that portion of the history you are trying to recreate has already been finalized.
Sure, if you get a majority of stake in the network, you can create alternative histories. But, as others have pointed out, this is much more difficult than a 51% attack in PoW.
The text "At most, all slashing does is makes Step 3 take more time." makes it pretty clear that I understand that completely. If you can suggest a revision to my comment that makes it more clear I'd be happy to mae it.
> has already been finalized.
This is presuming the existance of an external consensus mechanism.
FWIW, I've successfully acquired (often at next to cost) significant amounts of old spent Bitcoin wallets for the purpose of collecting dust sent to them, spinoff coins, and similar.
Mind you, Bitcoin had the same issues and they solved it with hard coded checkpoints.
There's no reason this can't be solved with timestamps and some sort of checkpoint mechanism. Many coins have done this with no issues, and others with issues have hard coded alternative checkpoints for forked chains.
Why would a client ever reasonably revert to a chain back in time 1 day without human intervention? If someone could explain in what extraordinary remote case this would be reasonable, I might be able to comprehend the maxis.
An extremely large number of cryptocurrencies are essentially completely centralized and only pretending to be decentralized as a regulation dodge. Centeralized systems can be extremely secure-- until the central parties decide to screw you over.
Bitcoin does have a thing called "checkpoint" but it is essentially completely unrelated to the centralized consensus mechanisms (usually a broadcast message signed by developers that force all nodes to switch to a chain with blocks that they've signed) added to many other altcoins which have used the same name for deceptive reasons to disguise their centralized control.
In Bitcoin there is a problem that the minimum POW difficulty was set based on 2009 CPU speeds just hundreds of thousands of hashes per-second, so at minimum difficulty a block requires 2^32 hashes to create. A single modern asic miner can perform 68 trillion hashes per second using a couple kilowatts. So, one of these devices could generate about 16k blocks per second at minimum difficulty.
This creates an issue where an attacker could fork the chain early on and create an incredible number of blocks at the minimum difficulty and feed them to your node. Your node wouldn't be sure if this chain of minimum difficulty blocks might not eventually add up to more work than whatever is your current chain, so it stores them. Eventually, this would exhaust your memory and disk and crash your node.
Currently, this attack is blocked by checkpoints that cause your node to ignore forks created from the chain back before the difficulty reached ~2^32 back in 2014 (so 2^64 work required to create a block). That's all checkpoints do.
There are alternative proposals to eliminate this problem which people are working on from time to time... and which have included adding consensus rules to increase the minimum difficulty (except for the earliest blocks), or making it possible to efficiently produce a compact proof of the total work behind a particular best block. But changes to consensus rules are fairly slow and hard to accomplish, so for the moment the adhoc fix protect nodes from an otherwise completely practical attack. Once one of these other fixes is implemented the 'checkpoints' would go away completely.
And never did they operate like 'checkpoints' in most other cryptocurrencies.
> client ever reasonably revert to a chain back in time 1 day without human intervention
Refusal to reorg at threshold X (for whatever X you choose) only creates vulnerabilities it doesn't resolve them:
Consider, if an attacker can't create enough blocks to produce a reorg X back from the tip then a refusal to reorg would simply be pointless (because the expected attack couldn't happen), so implicitly you're assuming the attacker can do that. If he can, then he can also create a fork right at X-1 and simultaneously announce it to whatever subset of the network he likes, carving the network into an arbitrarily shaped partition. If both sides have hashpower, both will continue on past block X-1 to X and and beyond on their own (and he can even contribute). They'll never heal on their own, the network becomes fragmented and exploitable in realtime. So the style of attack changes a bit but the ability of a supermajority hashpower attacker to reorg/disrupt the chain isn't materially reduced.
Worse, the refusal to reorg creates a whole new problem that didn't exist before: If a node was offline (say for days, months, years, or just coming online for the first time) then an attacker which didn't have anywhere near enough hashpower to successfully reorg near the tip could still (perhaps slowly over months) produce a X-long fork off an _earlier_ position in the chain and then aggressively feed it to nodes which are coming back online and redirect them into an attacker controlled bizarro-world which they won't recover from (without a user somehow discovering that they're on the 'wrong' chain and doing some unspecified action to fix them). This class of attack can be made more potent by DOS attacking a target's running node, forcing them to bring up new or backup nodes. This and similar attacks are an entire class of attacks created outright by a refusal to reorg.
Essentially the only case where a refusal to reorg is unambiguously safe is when you assume attackers lack the hashpower to cause the reorg in the first place. In which case... why bother?
As an aside, I think repeating an insult likening Bitcoin users to feminine hygiene products is extremely unprofessional and inappropriate for hacker news.
I know nothing about "feminine products". If you are referring to "maxis", it obviously means "Bitcoin maximalists." A google search of "maxis" over a vpn returns "Maxis is an American video game developer". A google search for "bitcoin maxis" quickly explains the usage of the word. I'm sorry you find this offensive, but I intended fully to name you a Bitcoin maximalist.
I don't see the need to continue if we've stumbled over something so trivial.
"network partitioning risk" is an aspect of many issues, such as the Sybil attack. Just because the Sybil attack exists in the Bitcoin ecosystem doesn't mean it's a game stopper.
The same solutions that solve many kinds of bootstrapping problems can easily be employed to stop fragmentation problems. Also, I want attacker chains to be fragmented. Fragmentation isn't always negative.
If my node decides to revert to a chain past a few hours, I want it to stop and manually ask me what chain to follow. This is exactly why checkpoints were added to Bitcoin and checkpoint like systems are employed by many coins. Checkpoints represent human input, manually making a decision. Blockchain is a voting automation system, it is not a replacement for my voice.
This isn't just theory, but practice! Bitcoin Core version 0.8 _broke the bitcoin network_. Humans had to manually pick a chain and manually revert to an older version of software. And yet no apocalypse materialized.
All prior versions before 0.8 were self-inconsistent-- accepting or rejecting some large blocks depending on their own history of orphaning and reorgs which would be different on different nodes-- and would have split all on their own eventually.
The distinction with 0.8 is that it made the maximum block size that a miner would create command-line configurable and larger blocks have a much easier time triggering the pre-0.8 inconsistency.
People originally thought that 0.8 was at fault since this happened a little while after 0.8's release and the first diverged node-pair people looked at were 0.8 vs 0.7. But that belief was mistaken.
> manually revert to an older version of software
Only a few percent of nodes had split there. The vast majority were on the more restrictive fork. I'm not, for example, aware of any exchange that observed a reorg from this.
> If my node decides to revert to a chain past a few hours, I want it to stop and manually ask me what chain to follow. This is exactly why checkpoints were added to Bitcoin
That was not why they were added and they have never had a behavior like that.
Stopping can be acceptable for some uses, but it's not a safe behavior in general and could dramatically exacerbate a network fault.
FWIW, ethereum will not stop in a big reorg. However, ethereum nodes do randomly stop for no reason whatsoever, and businesses have responded by automating blowing away the state of stuck nodes and re-warp syncing it against the network. The effect of this has been to essentially downgrade these exchanges to no-better than SPV security: they'll trust whatever gets mined.
> checkpoint like systems are employed by many coins
I'm not aware of systems like Bitcoin used by other altcoins, I am aware of quite a few where the developers broadcast signatures the rig the consensus which call themselves 'checkpoints' in order to deliberately deceive users about the security properties through an erroneous comparison to bitcoin like the one you're making.
Step 1. Acquire crypto currency. Step 2. Stake. Step 3. unstake and sell cryptocurrency. Step 4. use older keys to produce an alternative history.
Or, to simplify things, let other people do 1/2/3. Then purchase or hack their now-worthless old used keys to use in your attack... keys which they have no reason to protect and/or not sell. At most, all slashing does is makes Step 3 take more time.
I say "at most" because it doesn't necessarily do that much: if the funds you can earn from the attack (from double-spends and/or shorts) are large compared to the staked amounts, then step 3 isn't even required.
POS is fundamentally circular: you use ownership to determine ownership.
The only solution to this is to introduce another consensus mechanism like POW or, more commonly in POS proposals, a centralized authority. Some just assume the users are communicating over a synchronous lossless global totally ordered reliable broadcast-- which, again, is equivalent to running on top of another consensus system.
There is a reason you see people promoting POS that have an established history of committing fraud: the idea is most convincing if you obfscuate the details so much that no one is going to be willing to waste their time reviewing it. This is one of the classic moves used to convince someone to agree to a fradulent deal-- baffle 'em with bullshit.