You're probably right on both counts. Having said that, if the analysis is correct, then it means that users will eventually drive the chain to a place where it's experiencing regular attack. At that point they'll probably not stay around and will look for other options.
While a 51% attack is a real concern, an even more likely scenario is the network going down. During a network split the local node(s) will happily continue to ingest logs which once the network is healed will all be rejected.
That's an increase in clients, not Entry/Exit nodes. Until they begin flipping over into nodes there is nothing to worry about wrt this type of attack from a freak influx of clients.
There's a shelf life to this attack for each distributer though. You'll eventually distribute to users who _do_ understand what's happening and they'll raise alarms.
With the article, it can go unsuspecting for years even simply waiting for maximum distribution and then a coordinated attack.
It would be interesting to talk through that threat model, I think the over all network can be much more resilient to that sort of sustained attack than you're presuming.
You have two school of thought here... optimist vs pessimist.
Remember that the attack affects mostly client implementations therefore still needs proximity to victim(s), this makes most of the end-of-the-world type scenarios impractical (they even state these on their QA) and leaves exploitation to direct/APT-groups alone.
That's a pretty clear description of an attack, thanks.
> The honest source code has a change in the author signature
I assume we're talking about the scenario where a user has already-installed honest software that has validated the chain, but has been offline for a while?
If we were talking about a new entrant, just the fact that users' internet is often controlled by an attacker 50% of the time would probably be enough to trick users into downloading malicious software. If 50% of connections are hijacked, most users would probably not check signatures and so ~50% of them would get malicious software, the users that do check signatures would get honest software 25% of the time, malicious software 25% of the time, and a sig mismatch 50% of the time. There's some bad things that can happen there for any software where security is important. So let's stick to the scenario where the user already has honest software.
First I want to comment on the scenario, and then I'll outline a procedure allows the user to determine which is the honest chain.
> The honest chain has a large-scale validator drop caused by an outage of AWS US East 1
The outage you mentioned lasted less than 2 hours. But I think we can consider an outage that lasts say, 1 week. Kind of an absurd amount of time for an outage that hits such a huge amount of people, but even a 1 month outage would not give an attacker an opportunity here. And how many validators would drop out in this scenario? 20%? 40%? Any significant percent seems highly unlikely, but let's say it is a 40% drop for 1 week.
> The malicious chain has a large-scale validator drop at the same time caused by the malicious validator failing to include re-staking transactions
VPoS doesn't do staking, but the equivalent here is that the malicious chain would simply have blocks submitted at longer intervals until the "difficulty" re-adjusts, which would both equivalently indicate fewer validators.
> resulting in the malicious validator controlling 51% of the coins on the malicious chain
The malicious validator can mint in secret and always control 100% of the coins actively minting on the chain, no? This still doesn't help tho, because the honest chain can be seen to have more active validators than the malicious chain.
In a quorum-based system like Casper where the quorum chooses new randomness that determines the next quorum, it could be possible for an attacker to capture the quorum if they currently make up a large minority of the quorum and 40% of the rest of the quorum drops out. They'd have to have to make up at least 30% of the quorum, so that when they stop responding in the honest quorum, the honest quorum only has 30% left (matching their 30%). An attacker could 51% attack the honest chain in this scenario, no need for a separate malicious chain.
This is the same in bitcion - if 40% of the hashpower went offline, an attacker with only 30% of the hashpower would turn into an attacker with 50% of the hashpower. VPoS isn't quorum-based, but it would have the same problem if 40% of minters lose access to their coins for a period of time. Am I misunderstanding your scenario here? Seems like the move would be to 51% attack the honest network rather than try to attack a smaller set of nodes that are probably lower value.
> there are a lot of missed blocks on the honest chain, so traffic eventually falls back to a different validator to allow the blockchain to progress
I'm not sure about other PoS protocols, but in VPoS, there is no "fall back". The block progression simply slows and "difficulty" readjusts over time. The set of validators and how they're chosen wouldn't change.
But let me suggest a different attack scenario: let's say the attacker finds, creates, or buys old keys that collectively contain as much coins as the total coins minting honestly (a history attack). No need for an amazon outage. The attacker simply creates a chain from the point where those addresses collectively had as much minting power as the honest chain. After a time, they would capture all the randomness, and could put even more coins to work minting (with the use of stake grinding), which could look like a heavier chain (with more validators) than the honest chain.
> The honest chain has blocks validated every 20 seconds (this number pulled from Cardano), which were validated at that rate because honest nodes wouldn't accept a block earlier than the allotted time. The malicious chain has blocks that were all created in a span 20 minutes and signed by staking addresses controlled.
It sounds like you mean that the honest chain has one block every 20 seconds, whereas the malicious chain has a potentially unlimited number of blocks per second. Is that what you're saying?
I think in every PoS protocol, there is some verifiable time limiation. Yes an attacker could create an alternate chain starting from from 5 years ago in arbitrarily little time. However, they could not create more blocks in their fake 5 years of time than the honest chain did in real 5 years. And nodes obviously won't accept blocks with timestamps significantly in the future. Protocols have adjustments made when blocks have timestamps that are too close together, just like bitcoin. Any attacker that creates a chain with timestamps too close together will reduce their ability to create blocks proportionately.
But maybe you could clarify what you mean here.
In any case, to answer your primary question, this is a process that could happen:
1. User downloads honest software in 2021 and runs it continuously and/or regularly.
2. The user shuts down their software in 2022 and gets hit by a car and goes into a coma or something.
3. The user wakes up in 2026 and of course the first thing they do is start up their computer along with the currency software.
4. The software tells the user its been disconnected from the chain for too long and needs a new checkpoint.
5. The user goes to the website they're used to and downloads a new checkpoint and a signature for it (or ideally a battery of signatures).
6. The user uploads the checkpoint and signature(s) into the software. The software checks the signatures against the checkpoint and against its list of trusted public keys. Let's say none match.
7. So the user scours the internet and finds many (honest) articles that talk about how the dev group had a big change up and all the signatures are expected to be created with different keys now.
8. So the user goes and finds some new public keys to validate against. Chances are they go to a search engine and search a few places for keys. There's a 50% chance that they land on a malicious page, and they'll probably keep using that same page for subsequent searches. So 50% chance they get public keys from the attacker. If they're ultra careful, they could start a new web page (and connection) for each search and so only have a 50% chance of getting a malicious public key for each key - but lets just say they don't do that and so 50% of the users just get malicious keys.
9. The user puts in these keys and 50% of the time they match. In the case they don't match, an alarm is raised and they're alerted to the fact that they're possibly being scammed/attacked. 25% of users get malicious keys that matched the checkpoint data.
10. The software then connects to the network. While normally the software might use 8 connections like bitcoin does (tho double that is probably warranted), just for this case of validating the checkpoint, many more connections can be used. 100 wouldn't be very burdensome on the network, but would make it incredibly unlikely that a user would be eclipsed. Again 50% of these connections would be redirected to malicious nodes. Let's also say the attacker has a 50% Sybil in the network, so that even connections that aren't redirected by the attacker may still end up connecting to an attacker. So this is a 75% chance of connecting to an attacker. This results in a .75^100 chance that all their connections are to an attacker. If every person in the world tried to reconnect an old node during the attack window, there would be a probability of less than 0.3% that even a single person gets eclipsed.
11. The software asks these connections what their checkpoint is. If any don't match, an alarm is raised and the user is told they may be being attacked and told to verify out of band what the checkpoint is.
This is a good point I hadn't really considered - for the massive attacks typically there are pretty thorough write ups about exactly what it does, etc. so that maybe reassurances enough.
Very likely. It happens all of the time. If you read through some cve’s or other bug reports or post mortem’s, you’ll be surprised just how complex attacks can be.
reply