Hacker News Reader

Comment by josnyder | Hacker News Reader

PoW systems rely on the "phone a friend method" as well. When you download a Bitcoin client from a "friend", you are trusting them to honestly introduce you to the network. If you fall asleep for a period of years, you have to trust your friends to honestly inform you of all of the PoW forks and policy changes that have occurred over that interval. The only difference is that PoS blockchain clients must be bundled with a modestly-recent block hash along with the thousands of lines of code that you have no practical way to audit.

The problem eventually reduces to Ken Thompson's "Trusting Trust" [1] problem. There's no way to externally validate the honesty of any system (cryptocurrency, or otherwise).

[1] https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...

View on HN

You really don't need to trust a "friend" while bootstrapping into the network with PoW, because the proof of work is irrevocably embedded within the blockchain, and the real world cost of creating those blocks can be pretty easily estimated.

So long as you have a general idea of how much hash power is being used currently for the network, or even just how efficient ASIC computing is in general at your point in history, you can work out how great the hashing difficulty should be. You can trivially verify that the block hash with a large number of preceding zeros, e.g. 0000000000000000000b98dd8e7504793c0644cb0c27eb98f06aab9ea93c4ec2, is the hash of block it's attached to, and that a hash value that small would require a huge amount of energy to find. And every block beneath it also required a huge amount of energy, creating a huge real world economic cost to produce. You can't fake that chain without equivalent sacrifice of energy and compute resources.

Anyone trying to deceive you with a false chain would have to expend approximately as much energy as the entire legitimate bitcoin network does, and then keep doing it for as long as they want to deceive you. Sure, that theoretically could happen, but the economic incentives to do it just aren't there.

It seems that PoW does not need phone a friend to compare "which of these two chains is the true one", whilst PoS does need phone a friend for that.

However, that presumes all forks are soft forks; that you are presented a correct chain; that you want the soft fork with consensus rules accepted by most miners. (If verifying with an old bitcoin client the BCH BCT split will be resolved for you without you having a say.

In summary, PoW has less need for Phone a Friend than PoS. But it still has some problems.

Same thing applies to PoS.

How the hell do you know? You've just admitted that you don't actually know how PoS and PoW work. You've repeatedly refused to "do your homework" by researching what's known about these things. And yet you have repeatedly been rude to other people who have done their homework, and have informed opinions, unlike you. Just shut up and stop talking about blockchains. You're an entitled internet nobody.

For other people: https://news.ycombinator.com/item?id=29367857

I will talk about whatever I want to talk. If you don't like it, too bad.

I have regrets about calling you a "nobody". I was annoyed, but that's going too far, and I apologise for saying that. Almost no one deserves that level of vitriol, especially if at worst they're just being annoying. And I think I get annoyed too quickly.

If Bitcoin cash had more mining power than Bitcoin would it be called Bitcoin instead?

What if Bitcoin and Bitcoin cash had the exact same amount of hashing? Which is the true Bitcoin and why?

Indeed. And even if you posit a PoW currency which never has policy changes, unlike Bitcoin or any other major cryptocurrency…

And you assume that attackers will never have enough computing resources to execute a 51% attack – which could happen because the currency’s value falls enough that people stop mining it, because an extraordinarily well-funded entity decides to attack it, or because someone manages to hack the miners…

Then you do gain the security guarantee that if you see multiple competing branches of the blockchain, you’ll know which branch is the correct one (namely, whichever is longest). However, you’re still relying on phoning your “friends” (nodes you’re aware of) to tell you what blocks exist! If they all keep the true longest branch a secret from you (or, say, someone blocks your Internet connection to the nodes that aren’t willing to do so), then you will think the next longest branch is the correct one.

To be fair, that isn’t the most practical attack. But none of the risks being discussed here are remotely practical. In practice, nobody wants to connect an outdated client to a blockchain network because it risks (a) getting yourself exploited through known vulnerabilities in the client, (b) not working due to backwards incompatible protocol changes or bugs, or (c) missing a hard fork that might have happened over disagreements in policy changes (because there are always policy changes). So you update your client, and that means you have to rely on a “friend” to tell you which software you should be running.

Note that for bitcoin, because of soft forks, you could take a really old client and still find the 'true' chain.

What you describe is indeed a viable threat in certain conditions.

It's called "Eclipse Attack". But it's a threat for single nodes not for the network as a whole.

> But it's a threat for single nodes not for the network as a whole.

Indeed, but the same is true for attacks on "weak subjectivity" proof-of-stake. They're only a threat for nodes that have been disconnected for a long time (months) before they try to reconnect.

Except for the part where eclipse attacks can be resolved by simply feeding my node more data (it's not a problem if some of it is lies), while "weak subjectivity" requires recourse to an external authority.

i don't know as much about this as you, but it seems to me that the attack you describe in the blog post would also require a successful eclipse attack?

My understanding is that the attack you describe involves a cabal of "evil" validators signing some alternate chain (call it the "fake" chain) long after their stake is withdrawn, creating a fork in the distant past. Before they did this, they pretended to be good validators, which meant they signed the "real" chain's blocks and then signed the withdraw transaction. So after the attack, there are two conflicting sets of signatures signed using the evil cabal's private keys; those on the fake chain, and those on the real chain. So anyone in possession of both of these sets of signatures can conclude that the validators in the cabal are "evil", and then they can see that once the cabal's support is removed from consideration, the real chain had more valid validator support (at the time of the fork, in the distant past). If this line of reasoning is correct, that suggests that anyone who is aware of both sets of signatures can identify the real chain?

> So after the attack, there are two conflicting sets of signatures signed using the evil cabal's private keys; those on the fake chain, and those on the real chain. So anyone in possession of both of these sets of signatures can conclude that the validators in the cabal are "evil", and then they can see that once the cabal's support is removed from consideration, the real chain had more valid validator support (at the time of the fork, in the distant past).

I think this is where you get the problem - if you just have two sets of signatures, how do you tell which is legitimate and which one isn't? How do you conclude in which set the cabal was lying?

An eclipse attack is so named because it requires you to keep all the light out so they're kept in the dark. But here, since there's no internal mechanism to tell the two chains apart, you don't only need the accurate information, but also outside information about which one is accurate.

If you actually see two conflicting chains (either proof-of-work or proof-of-stake) with large numbers of people vouching for both, then the correct chain is not necessarily "whichever one is longer". Well, it could be, for you; "correct" is subjective. But by assumption in this scenario, a large number of people disagree, and you might want to transact with some of them. There is no way for software to decide this objectively; it has to ask the user to decide based on factors external to the network.

Where proof-of-work really does have an advantage is that you can more easily distinguish that scenario from the scenario where either one of the chains is actually a Sybil attack, i.e. a single attacker pretending to be a large number of people. Similarly, if you only see a single chain, with proof-of-work you can try to detect an eclipse attack (which implies a Sybil attack) by seeing if the hashrate has gone down dramatically.

That's a real advantage. I don't think it's even close to enough to mitigate proof of work's disadvantages, especially since the circumstances where it would practically come into play are extremely unlikely, but it's not nothing.

However, it's undermined by the fact that proof of work naturally encourages centralization. Bitcoin is centralized enough that it's not completely impossible for the vast majority of the hashrate to end up on one side of a fork (either soft or hard), while the vast majority of users and developers end up on the other side. (To be clear, this is very, very unlikely to actually happen, but so are all of the attacks we're talking about.) If this happens, the objective proof-of-work standard will side with the miners, but not with the people you actually want to transact with.

Of course, a proof of stake currency can also suffer a schism, but there is (probably) less tendency for stakers to be centralized, and if a schism did occur, at least the client wouldn't provide a false sense of objectivity.

None of this actually refutes my point. You're just suggesting that the fact that PoS is incapable of producing a consensus is outweighed by it allegedly being more decentralized. Be that as it may, it's not relevant to this thread.

Is it even true? Steemit had the exchanges do a hostile takeover, because everyone was staking through them.

> I think this is where you get the problem - if you just have two sets of signatures, how do you tell which is legitimate and which one isn't? How do you conclude in which set the cabal was lying?

I feel like you should be able to deduce it from the distribution of participation after the fork, right?

The “fake” chain would lose all honest verifiers (and all transactions from honest wallets?) which seems like it would be pretty detectable with simple statistical analysis. Staked nodes not participating (and active wallets not transacting) becomes less and less likely the longer the post-fork chain is.

> The “fake” chain would lose all honest verifiers (and all transactions from honest wallets?) which seems like it would be pretty detectable with simple statistical analysis. Staked nodes not participating (and active wallets not transacting) becomes less and less likely the longer the post-fork chain is.

But you don't know who's honest - you may as well be saying the real chain lost all the dishonest verifiers.

Exactly - that's where statistical analysis (like fakespot) comes in.

For each chain you'd be able to look at the age, stake & historical participation level of the post-fork participants and get a pretty good idea which (if either) of the chains is real. The absence of honest participants should look a lot different than the absence of dishonest ones.

Granted, this method is not nearly as simple as checking the number of 0s on a hash, but I would imagine it to be quite difficult to circumvent.

How do you know what are honest verifiers and wallets?

You any specific verifier/wallet, you won't - but the fake chain will have 0 uncompromised actors after the fork.

Which means that large stakeholders suddenly stop verifying blocks. Long-term active wallets stop transacting.

The same might be true for both chains after the fork, but I would imagine the fake one would have a larger change in participation (weighting older wallets and larger stakes) than the real one.

I think the difference is which kind of hash you needed.

For PoW, you'd have to know the hash of the start of the chain (the "genesis block") in advance to verify you downloaded the correct chain. That's true, but this hash doesn't change during operation. You could get that hash from a history book if you will.

For PoS, the hash is from the end of the chain and therefore constantly changing. This means the challenge of finding out whether the hash is the right one is a lot more real than in the PoW case, because there is no "common knowledge" to go by which hash is right.

> For PoW, you'd have to know the hash of the start of the chain (the "genesis block") in advance to verify you downloaded the correct chain.

Nope. You could fork the chain at a period of low difficulty and it would still stem from the genesis block. It would either be a short chain, or have clearly low difficulty though, so it wouldnt fool anyone knowledgeable. Im not sure how you would leverage that chain for fraud.

Why fork at low difficulty?

You need to fork at low difficulty if you want to significantly lengthen the chain from that point, because creating a high difficulty, long chain that is valid is hard.

But-- there's nothing to preclude you making big steps up in difficulty at the end of the chain. It means that one evaluating the length of the chain for authenticity really needs to integrate the difficulty over the entire chain and not just look at the number of blocks.

I was wondering about that bit actually.

Suppose I'm a new node and want to verify the blockchain. How do I verify that each block was mined with the correct difficulty?

I'd need some record about the actual real-world timestamps for each block. Then I could say something like "duration between block x and block x+1 was > 10 min, so the down-adjustment in block x+5 is justified".

But if those timestamps were stored on-chain, an attacker could simply lie about them and keep difficulty artificially low on its alternative chain.

On the other hand, if we had some un-forgeable record of block timestamps, wouldn't this solve the double-spend problem all on its own? Would we even need PoW at this point?

Edit:

Ok, sibling comment seems to suggest bitcoin has solved this problem differently: https://news.ycombinator.com/item?id=29368166

Yes, Bitcoin effectively integrates the difficulty over the entire chain.

A while ago bitcoin clients changed from facoring the 'longest' chain to favoring the chain with the most work done on it. (To prevent long chains with low difficulty)

So... the consensus rules of the network changed, you need to make sure you have the correct client, and bitcoin is weakly subjective after all?

Asking "what's the correct client?" will always be a subjective question

Bitcoin doesn't decide what is called bitcoin, we as a community do

In practice this was essentially a soft-fork. But yes the consensus rules of bitcoin software changed.

The client can choose properly, but it needs to "call a friend" in order to get the options - if the client doesn't receive the proper chain but only fake ones, it will chose the fake one with the most work done on it.

Because of withdrawal delays, the PoS hash isn't from the end of the chain, but from a few months before. So it changes only about as often as client software updates.

> For PoW, you'd have to know the hash of the start of the chain (the "genesis block") in advance to verify you downloaded the correct chain.

No. For Bitcoin you can accept a chain with an arbitrary starting point and you would still arrive at the same chain everyone else uses.

Although you do need to have an idea of the earliest acceptable starting point-in-time — e.g. verifying a low-difficulty chain starting the year 200,000 BC (with one block every 10 minutes) would take quite a while

Finally someone actually mentioning the code. In PoS "trust" must exist along several points in time before you can engage with the system - and the most notable point being trusting that the rules (written in the code) are of your desire.

With PoW you don't care about the software code. The rules are dominated by the PoW because it literally proves to you which is the chain where most people are interested in, because literally no single entity could burn that much electricity.

With PoS on the other hand you kind of need these checkpoints in the actual software and then you have to activate this entire new trust model where you have to trust the client code, and where it came from etc. I could literally come up with an entire fake chain on my computer and present it to you and without client-checkpoints there would be no way for you to not accept my chain compared to your current one.

With PoW I don't have to trust anything. If the majority next year decides to change the rules, so be it. The majority has spoken.

If you don't trust the code of a PoW client, how could you trust it to not simply empty your wallet as soon as you import your private key?

I was talking about the consensus part. You don't need any client code to understand which is the agreed-upon chain, you verify the hash was generated using lots of energy.

For transacting indeed you need to trust the various clients, but that's easy and can be done once. With the consensus isn't being tampered with, and, more importantly that others are using other types of rules.

Is the threat of long range attacks in PoS any worse than PoW in practice?

Bitcoin for example still relies on a list of hardcoded nodes for bootstrapping clients. Not to mention very few people actually bother to verify the full chain (360GB and counting) from genesis.

As for auditing the the integrity of the code or binary, it is signed by GPG keys hosted on public key servers accessed using X509 certificates pinned by a a couple of trust anchors preloaded in your OS. So much for distributed consensus...

The Bitcoin Core client includes a hardcoded list of DNS servers that point to thousands of nodes. These lists get updated frequently by different people. Other clients may use other lists. What is the threat model you're suggesting here, exactly? Do you know any other way to bootstrap a peer to peer network without centralised authorities?

All network participants are forced to verify the full chain from genesis. Some might be OK with validating block header signatures only, and not the full transaction set. It's a tradeoff.

You don't need to use those public key servers if you somehow distrust the CA certificates in your OS. Feel free to contact the repository maintainers or whatever else floats your boat.

Anyway, bitcoin is an open source protocol, not a particular client implementation. If you distrust everything and everyone, no one can stop you from building your own client that works with the rest of the network.

> Do you know any other way to bootstrap a peer to peer network without centralised authorities?

I’m not the parent, but – no, I don’t. But that’s exactly the point. The need to bootstrap from centralized authorities is what’s supposedly so bad about weak subjectivity in proof-of-stake. Yet in practice, it’s needed with proof-of-work as well.

Hi Nick, very well said and this is precisely my point as well.

Satoshi tried to convince us that we could decentralise trust by doing honest work instead of relying on authority. It turns out that doing work is actually pretty hard, people are lazy, and security is still the nemesis of efficiency.

Maybe I didn't word it right, but I wasn't calling bitcoin's method reliant on centralised authorities, just asking if there were more methods out there that weren't as well.

Bitcoin is an open source permissionless protocol, so you have multiple clients to chose from, each with their own list of bootstrapping nodes, many open source where you can submit a PR to add your node too. You can even build your own client and point to whatever you want. You can also just ignore them and just point directly to nodes in a list from a public forum, a private chat, whatever.

Also, you're not just connected to those bootstrapping nodes: you use them to find the rest of the peers in the network.

It seems that PoW is like recursion. You don't get it at all until you completely get it. It's a leap to understand it and somehow many very technical people don't understand a seemingly simple protocol even a decade after it became mainstream and is threatening national banks due to the very characteristics these people claim it doesn't have.

Indeed, a very strange phenomena. Willful ignorance?

> Bitcoin is an open source permissionless protocol, so you have multiple clients to chose from, each with their own list of bootstrapping nodes, many open source where you can submit a PR to add your node too. You can even build your own client and point to whatever you want. You can also just ignore them and just point directly to nodes in a list from a public forum, a private chat, whatever.

I characterized this as relying on centralized authorities (albeit several of them), but sure, it can also be considered decentralized to some extent.

The point is that it's a mechanism outside of the proof-of-work network itself. Instead of relying on a machine to reach consensus via a formal protocol, you the human are probing for a social consensus by evaluating statements made by other humans (via GitHub, public forums, or private chats, or just talking to people in person).

In both proof-of-work and proof-of-stake, you need to find social consensus in order to initially obtain the software, after which point you can rely on the network's consensus.

The difference with proof-of-stake is that you have to redo this if you disconnect from the network for months on end.

In practice, for a variety of reasons, practically all users of cryptocurrencies download regular software updates, and thus continue to rely on social consensus, regardless of whether the currency is proof-of-work or proof-of-stake.

I want to take a moment to note what you're doing here. You're making a negative argument, in want of a better word. It goes something like this:

1. X is a problem?

2. But Y is also a problem, in my opinion.

3. X and Y are both the same, I think.

4. Therefore X is not a problem.

We can - theoretically - verify the correctness of PoW software by downloading the source code, reading it over, etc. We can also refuse to update, reducing ourselves to SPV security. We can internally verify the checkpoints using 100% objective standards. There are other things as well. This is not the case for PoS, where our "signature A existed at time B" has to be taken as faith, or evidence of things unseen. There is no internal way to verify the veracity of such a statement.

The fact that users aren't personally doing this, is not the same as saying it makes no difference whether they are able to or not. I'm not personally going to withdraw all the money in my bank account - that would be ridiculous - but if the bank informed me I was no longer able to withdraw the money in my account, that would not be suitable at all. The assurance that I can do it makes it so that I don't have to.

> 3. X and Y are both the same, I think.

It seems like you reject this premise, maintaining that PoW networks are objectively verifiable? But you didn't really refute the parent's point there, which was that there are no "objective standards" in deciding which bootstrap nodes to use; it's ultimately a matter of trust. If I trust the wrong bootstrap nodes, I can be eclipsed from the real network.

Granted, I only have to trust that a single bootstrap node from the list will faithfully connect me to the honest network. But PoS involves a very similar 1-of-n trust model; I can request checkpoints from n semi-trusted sources and check that they match.

Also, granted, if I pick bad bootstrap nodes, I can still detect if I'm being eclipsed by looking at the hash rate. But how do I know what hash rate to expect? I could check n websites with hash rate charts, but that brings us back to 1-of-n trust.

> 4. Therefore X is not a problem.

IMO it's a manageable problem. Users just need to be cognisant of these trust assumptions they're relying on, and be thoughtful about picking semi-trusted peers (whether bootstrap nodes or checkpoint providers).

> It seems like you reject this premise, maintaining that PoW networks are objectively verifiable? But you didn't really refute the parent's point there, which was that there are no "objective standards" in deciding which bootstrap nodes to use; it's ultimately a matter of trust. If I trust the wrong bootstrap nodes, I can be eclipsed from the real network.

Right, but it's not about trust in the same way. I can add an infinite list of bootstrap nodes. Quantity matters, not quality.

> But PoS involves a very similar 1-of-n trust model; I can request checkpoints from n semi-trusted sources and check that they match.

"Very similar," not the same. You need "semi-trusted sources", and there's no objective standard in case they disagree.

> Do you know any other way to bootstrap a peer to peer network without centralised authorities?

In IPv4 a client might have a chance at auto-discovering peers.

It's also not necessary to rely on a single centralized authority. There are many things (DNS, Encyclopedias, Linux kernel mirrors, etc.) where the majority of existing centralized authorities agree with each other.

DNS is based around central authority though. Every root zone has name servers that serve as the authority. Their responses get cached at various levels but take those servers offline until TTLs start expiring and everything breaks.

What part of DNS do you feel is possible without a centralized authority?

> Bitcoin for example still relies on a list of hardcoded nodes for bootstrapping clients.

It does, but it doesn't have to. You can use any mechanism you want to obtain one initial node and take it from there. You will still be connected to the network just as well, and you will be guaranteed to obtain the same results. This differs from Proof of Stake, where the quality of the results will be influenced by the quality of the bootstrap.

> As for auditing the the integrity of the code or binary, it is signed by GPG keys > hosted on public key servers accessed using X509 certificates pinned by a a > couple of trust anchors preloaded in your OS. So much for distributed consensus...

You can literally validate the entire chain with a simple python script. Millions of those on github.

>Not to mention very few people actually bother to verify the full chain (360GB and counting) from genesis.

Absolutely wrong. The chain is validated in its entirety upon first sync. 100% from genesis to tip.

>Bitcoin for example still relies on a list of hardcoded nodes for bootstrapping clients.

It doesn't. Longest valid chain with most work is the canonical chain. Hardcoded seed nodes exist to speed up the discovery.

> You can literally validate the entire chain with a simple python script.

I challenge you to present a "simple python script" that implements the exact bitcoin consensus rules (as codified in bitcoin core). Bitcoin is not all that simple and there's a nontrivial amount of complexity in bitcoin script alone [1].

> The chain is validated in its entirety upon first sync. 100% from genesis to tip.

The default behavior is to skip signature verification for all signatures before some relatively recent block [2].

[1] https://github.com/bitcoin/bitcoin/blob/master/src/script/in...

[2] https://github.com/bitcoin/bitcoin/pull/9484

You're misunderstanding the default behavior which is fine becaue it's commonly misunderstood and discussed. At any rate signature verification is not skipped by default, what assumevalid skips is script verification. Everything else including UXTO, proof of work, the transactions themselves, are validated.

That seems a bit pedantic; the client itself prints

> Assuming ancestors of block %s have valid signatures.

when using -assumevalid. I agree it's imprecise, but it's not exactly wrong, since skipping scripts implies skipping signatures.

I verified the full chain a couple of weeks ago (But I admit I trusted umbrel to choose the "correct" bitcoin-core software to run), It took less than 3 days to sync on a Rpi4

Trusting trustlessness is the paper you want to consult with

https://www.cs.umd.edu/~gasarch/BLOGPAPERS/cbit-4-2.pdf

'Policy changes' and hard forks have about as much to do with PoW as whether the Federal authorities should ban cryptocurrencies or not - they're outside the realm of consensus algorithms. In PoW there are no friends. If your blockchain is incorrect (i.e not the longest) your transactions on it are invalid and will be rejected by the rest of the network.

> If your blockchain is incorrect (i.e not the longest) your transactions on it are invalid

If your chain tip is on the dead side of a hard fork (i.e. if the majority of the network will predictably soon finish switching away from software which considers your chain tip valid, to software which considers your chain tip invalid), then nobody cares if your chain tip is the longest in the interrim, or how long you still hold out running the software that considers your chain tip valid. Your side of the fork no longer holds any economic value as a platform for transactions, so nobody will participate in it. You'll just be out there mining blocks all alone, blocks that say you earn all the virtual tokens, but where those tokens are worthless on your side of the fork.

It's a bit like how, in old pre *serv IRC networks, in cases of netsplits, you could end up on a partition of the network where you were the only one in a previously-moderated channel; and so you could effectively do whatever you wanted in that channel. But it didn't really matter, because nobody could hear you.

Um, yes. I should have phrased that as 'your transactions based on it are invalid in the network'. You just described consensus working correctly, but like I said hard-forks and policy changes are outside the scope of PoW, so saying PoW does not handle hard-forks is not really a valid criticism of PoW.

"nobody cares if your chain tip is the longest in the interrim,"

Except the people you bought something real-world from, once they figure out that their "tipcoin" is worthless. So now it's a question of convincing some people that your technobabble is valid enough. How hard is that?

No, policy changes makes for a new blockchain. That's what usually referred to as a "hard fork", as opposed to a "soft fork" where consensus rules are only allowed to get stricter, exactly beacuse ownership of a coin should be guaranteed forever.

You could follow the consensus rules set out from the beginning and you would still end up on today's majority chain.

I believe there were a couple of early bug fixes along the way, which makes this not strictly true. As in the original first release of the software not actually capable of downloading all of the chain, which some people love to point to as a proof of it being a fallible system. This is probably true but doesn't really detract from the original point of guaranteed ownership by never relaxing the consensus rules.

not really, if you fall asleep for a period of years, you can still get a signal of how genuine any proposed fork is by observing the chain of blocks and their difficulties. that's the crucial bit of any PoW system - you can't fake the energy that was spent producing the chain. that's a way to externally validate the honesty of a system and a major scientific breakthrough that satoshi discovered.

also, hi, long time! maksym here =)

The difference in Proof of Stake is a lawsuit could force the distributor of the software to change the hash to one where coins weren’t stolen. As most developers are not pseudonymous, this poses a threat to the honesty of the system.

You mention “POW forks”, but Bitcoin’s POW has never been hard forked: you’d need to trust a Bitcoin expert to tell you if it was a good idea.

> The difference in Proof of Stake is a lawsuit could force the distributor of the software to change the hash to one where coins weren’t stolen.

In Proof of Work, a lawsuit could force the distributor of the software to hard-code a transaction that reverses the coin theft. But in both the PoS case and the PoW case, anyone using that client would be partitioned off from the honest network majority.

> You mention “POW forks”, but Bitcoin’s POW has never been hard forked: you’d need to trust a Bitcoin expert to tell you if it was a good idea.

Bitcoin's PoW forked in 2013, when a database upgrade to the software made it incompatible between two recent versions. The Bitcoin developers had to jump in and tell people which PoW fork to follow and which one to abandon.

> The difference in Proof of Stake is a lawsuit could force the distributor of the software to change the hash to one where coins weren’t stolen.

And with proof of work a lawsuit could force the distributor to change the consensus rule so that a particular transaction is invalid - just as Ethereum did voluntarily with the original DAO.

> You mention “POW forks”, but Bitcoin’s POW has never been hard forked

Instead it’s been soft forked, which turns the consensus rules into a popularity contest. If a soft fork produces two competing branches of the blockchain, old clients will go with whichever branch has more mining power. Which means you open yourself up to interesting attacks like convincing 51% to literally steal the funds of the other 49% (which is much worse than a mere double spend). Or, more realistically, in the case of a contentious soft fork that ends up roughly fifty-fifty, you could ‘just’ end up on a different side of the fork from the people you want to transact with. Either way, soft forks don’t make the downsides of policy changes go away.

Changing consensus rules requires coordinating a fork. This requires coordinating developers, miners and node operators. That may fly in pseudo decentralised chains where the community accepts whatever the leader says so, and even so, at high risk. In bitcoin, for instance, where there is no leader, this would never be a viable scenario.

Soft forks don't force you to download and run new clients just to be able to use the network, which is an important difference. You can use your existing client, you just don't have the new features and don't run validations on them.

The greatest risk on soft forks is that chain split you mention. That's why any reasonable soft fork deployment requires a long time window with a large majority of hashrate signaling support (like 95%).

Changing a PoS checkpoint would also require coordinating a fork. Even if a dev team were forced to make the change, they couldn't make everyone go along with it.

Reply on news.ycombinator.com