Live data from Hacker News

Proof of stake is incapable of producing a consensus

yanmaani.github.io

711–720 of 822 posts

Re: Proof of stake is incapable of producing a consensus

#711
post #581

Earlier quoted context omitted.

You make it sound like I need a new hobby - which I might haha. > Do you consider nuclear energy sustainable? Low-carbon, yes. Sustainable, yes. Renewable, not until we productionize extraction of uranium from seawater. [1] > ... but do you believe nuclear, either fission or fusion, will play a large role in the future? Fusion if we can crack it, totally. Seems like a clear winner. Fission probably will if there's so…

This article is complete FUD. > of which the following sources are considered to be renewable in other words, it attempts to define the world "renewable" along favoured political ideologies. From Wikipedia: > Advances in breeder reactor technology could allow the current reserves of uranium to provide power for humanity for billions of years, thus making nuclear power a sustainable energy TL;DR: nuclear is just as re…

I saw the renewability as more of a thought exercise, because I agree with you, there's more than enough nuclear feedstock to keep us going indefinitely.

Re: Proof of stake is incapable of producing a consensus

#712

Earlier quoted context omitted.

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 va…

> 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.

Re: Proof of stake is incapable of producing a consensus

#713

Earlier quoted context omitted.

> This is a similar trust assumption to requiring that 51% of the mining power in PoW (Proof of Work) is not malicious. Yeah, but you're glossing over an important detail: It's not 66% of the stake that has to be good, it's 66% of anyone who has ever staked . In PoW, I only need to trust the miners of today to tell me the truth about what happened today. In PoS, I need that, plus the miners of yesterday, plus the min…

> It's not 66% of the stake that has to be good, it's 66% of anyone who has ever staked. In PoW, I only need to trust the miners of today to tell me the truth about what happened today. I don't quite get that. As far as I understand it the "nothing at stake" problem works by a malicious party inducing a fork, one of which they double-spend in. Since it's in the best interest for everyone else to mine both forks, you…

> If it is recognised that you mine on more than one fork at a time, you lose the security deposit you gave before the fork.

Yes, modern proof-of-stake algorithms work this way. The caveat is that at some point (on the order of months later) the security deposit is refunded, and at that point you can lie about the past without consequence. But this is a limited attack: you can only successfully lie to someone who has been offline since you were a staker, or else they would already have a record of the real successor chain (which now has a new set of stakers, who themselves still have their security deposit deposited).

Re: Proof of stake is incapable of producing a consensus

#714

(my day job is developer on Proof-of-Stake Algorand block chain, I'm a developer, this may not be polished official PR) Article's theory about malicious old blocks doesn't hold up. Let's say I start a new node and verify history since the beginning. Somewhere along the line I'm connected to a malicious node which hands me a fictionalized block. It would need to have been signed by not just one but about 30-45 account…

Glad to see an Algo dev here.

Re: Proof of stake is incapable of producing a consensus

#715
post #598

Earlier quoted context omitted.

I'm not sure what you are linking to. This looks like a tweet from 2016.

I think what the parent referring to is the DAO hack (from 2016) and how Ethereum’s response was to renege on “Code is Law” (and the integrity of the blockchain) in order to void those transactions (smartcontract exploits), which is a case of centralization resurfacing because VB could subvert the proof of work system when his own money was at risk. Ethereum Classic is the fork that refused to rewrite the blockchain…

"Code is Law" was never part of Ethereum's ethos. It was some meme created by the company behind The DAO, and perhaps many people in the community supported it, but it wasn't part of Ethereum.

Re: Proof of stake is incapable of producing a consensus

#716

Earlier quoted context omitted.

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 va…

> 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 t…

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.

Re: Proof of stake is incapable of producing a consensus

#717

Earlier quoted context omitted.

https://github.com/ethereum/annotated-spec/blob/master/phase... After withdrawal is completed, your node would no longer be in the set of active validators and from that time could not validly propose a block or submit an attestation (or, more accurately, be selected as a block proposer, etc.)

Yes, "validly" being the operative word here. I can still propose blocks invalidly, you see. And then someone who doesn't already have the consensus (e.g. trying to sync) will have no way to tell which is legitimate. This is the problem - you can't look at what the system does when everything's working as it should, you have to look at what happens when it's outside of the comfort zone.

Even a relatively light reading of the Annotated Specs for Eth2[1] and/or the Eth Org's Proof of Stake FAQs[2] suggests the designers (and independent implementer-teams who gave feedback to designers, who gave direction to the implementers... lather, rinse, repeat) understand it's important to consider the overall system "outside of the comfort zone".

[1] one such: https://github.com/ethereum/annotated-spec/blob/master/phase...

[2] https://eth.wiki/en/concepts/proof-of-stake-faqs

Re: Proof of stake is incapable of producing a consensus

#718
post #575

Earlier quoted context omitted.

You can fork decentralized over (crypto) collateralized stablecoins even if you can't force a fork of a centralized stablecoin operated by incorporated entity to be recognized by them. Unless we're going to pretend that there is only one way on and off networks and only in one currency denomination…

You can fork decentralized over (crypto) collateralized stablecoins In practice the value of the forked collateral is likely to be low, leaving the stablecoins insolvent.

If you are forking the chain state and not just the vm, that could be the case.

However, if you are only forking the vm and allowing for people de deploy other protocols (or forks of other protocols), this is not the case (they just start off at lower total supply relative to the native collateral available on that network from a lower demand base).

Re: Proof of stake is incapable of producing a consensus

#719
post #73

Earlier quoted context omitted.

I don't see how more confirmations makes it exponenrially harder to mount a 51% attack: you just need to be mining faster privately than the remaining community until you (a) have a lead, and (b) have maintained that lead for the confirmation window.

There's luck involved too. In the limiting case, imagine you have 0.001% of the network hash rate and need a 1 block lead. This can happen every now and then, but getting a 2 block lead is basically impossible. The exact formula is given in the Bitcoin whitepaper https://bitcoin.org/bitcoin.pdf >, see page 6 and on.

According to that formula, in a 51% attack, probability of success = 1 (since 51% attack means you are more likely to find a hash than all others combined), right?

Re: Proof of stake is incapable of producing a consensus

#720

Earlier quoted context omitted.

The service is worthless if you can trust a central authority like a government that 99.99% of people do.

There are many countries where people cannot trust a central authority like a government to keep their savings remotely safe and stable in value.

Even in those cases you can use dollars and trust the US government
Post reply on HN