Byzantium Hard Fork Announcement(blog.ethereum.org)
blog.ethereum.org
Byzantium Hard Fork Announcement
https://blog.ethereum.org/2017/10/12/byzantium-hf-announcement/
88 comments
The preprogrammed difficulty bomb is not to stop people who want to intentional stay on the old fork. It's to stop the old fork winning consensus by default due to people who don't actively upgrade.
Pushing through protocol changes could be hard if everyone who takes the default action of doing nothing is counted as a vote against any protocol change. I think we see this with bitcoin where change is very conservative and slow because any change has to gain enough support to be actively upgraded by a majority.
The difficulty bomb just means that if there is ever disagreement about a protocol change, everyone will have to actively choose a side rather than the 'no' side getting all the non-active default votes.
It basically just means that changes can be done faster.
Pushing through protocol changes could be hard if everyone who takes the default action of doing nothing is counted as a vote against any protocol change. I think we see this with bitcoin where change is very conservative and slow because any change has to gain enough support to be actively upgraded by a majority.
The difficulty bomb just means that if there is ever disagreement about a protocol change, everyone will have to actively choose a side rather than the 'no' side getting all the non-active default votes.
It basically just means that changes can be done faster.
>everyone will have to actively choose a side rather than the 'no' side getting all the non-active default votes
No, this just shifts the do-nothings from 'no' to 'yes', as they will have to actively create something that will let them stay with what they currently have. It is technically and morally dangerous because most people aren't technical enough to understand what they are being forced to accept.
No, this just shifts the do-nothings from 'no' to 'yes', as they will have to actively create something that will let them stay with what they currently have. It is technically and morally dangerous because most people aren't technical enough to understand what they are being forced to accept.
I'll confess to only knowing the surface concepts, not the inner technical workings, so I could be wrong here. But this is my understanding.
With a future difficutly bomb in the current implentation, when a proposed hard fork from the ethereum team is approaching you have 3 options:
Having the difficulty bomb guarantees that (eventually) all users post fork must have actively made a concious choice one way or the other and upgraded. The users that do nothing are guaranteed to end up on a dead chain, and hence have not cast a vote in either direction.
I'm not sure how that can be interpreted as the do-nothings casting yes votes. Anyone who does nothing becomes no part of any future chain.
With a future difficutly bomb in the current implentation, when a proposed hard fork from the ethereum team is approaching you have 3 options:
1) You do nothing (you don't vote - the default) - You'll end up on the chain that eventually get's it's difficulty scaled up and will die. You will not be able to continue running this chain practially after this point.
2) You agree with the fork (a yes vote) - You need to actively install the update.
3) You disagree with the fork (a no vote) - You need to activly install a competing patch to remove the bomb.
Having the difficulty bomb guarantees that (eventually) all users post fork must have actively made a concious choice one way or the other and upgraded. The users that do nothing are guaranteed to end up on a dead chain, and hence have not cast a vote in either direction.
I'm not sure how that can be interpreted as the do-nothings casting yes votes. Anyone who does nothing becomes no part of any future chain.
This isn't something that is forced. All of these are planned from the beginning. Frontier -> Homestead -> Metropolis -> Serenity.
Exactly. The Ice Ages have always been part of the plan. By installing a client with a built-in Ice Age, you're voluntarily joining a pact to upgrade at a certain point in the future. It's game theoretically effective for decentralized consensus.
They just released the fourth proof of concept for proof of stake, they've simplified the design so it's not much more complicated to implement than proof of work, and they've got some formal proofs of its properties. They're also working on a PoC for the initial sharding design. Here's the latest dev roundup:
https://blog.ethereum.org/2017/10/09/roundup-6/
https://blog.ethereum.org/2017/10/09/roundup-6/
In the blog post[1], on which Casper PoC4[2] is based, Vitalik writes:
> Accountable safety is what brings us this idea of “economic finality”: if two conflicting hashes get finalized (ie. a fork), then we have mathematical proof that a large set of validators must have violated some slashing condition, and we can submit evidence of this to the blockchain and penalize them.
Why would the validators, who decide what goes into blocks, willingly include a proof that they have cheated?
As far as I can see, these proofs must be communicated out-of-band (not through the blockchain) by nodes, since no validator would ever incriminate itself by including a proof that it has cheated.
How do nodes coordinate this, and come to agreement on which chain is the right one?
[1] https://medium.com/@VitalikButerin/minimal-slashing-conditio...
[2] https://github.com/ethereum/pyethereum/pull/809
> Accountable safety is what brings us this idea of “economic finality”: if two conflicting hashes get finalized (ie. a fork), then we have mathematical proof that a large set of validators must have violated some slashing condition, and we can submit evidence of this to the blockchain and penalize them.
Why would the validators, who decide what goes into blocks, willingly include a proof that they have cheated?
As far as I can see, these proofs must be communicated out-of-band (not through the blockchain) by nodes, since no validator would ever incriminate itself by including a proof that it has cheated.
How do nodes coordinate this, and come to agreement on which chain is the right one?
[1] https://medium.com/@VitalikButerin/minimal-slashing-conditio...
[2] https://github.com/ethereum/pyethereum/pull/809
I'm not sure but I think that (a) it does you no good to put your cheats only on your own node, they need to be public to give you a chance of profiting, and (b) therefore other staking nodes will see them, and can include them in the blocks they produce. They could even get rewarded for that.
Last time the Casper fork was discussed on HN I read through a very long and very dense document only to find out that Vitalik, or someone similar, had a key that decided which blocks were genuine, in case of dispute. I take it that design has not changed? In that case I am surprised the design could not be simplified further.
Eh, no, there's no special Vitalik key.
How do nodes choose which fork — past the latest checkpoint — to view as the main chain?
E.g. let’s say I take the main chain, go back to the first block past the latest checkpoint, and remove the competing staking-transactions so that only my staking-transaction is present in that block. The I build on top of this, without competition, because I can selectively remove competing staking transactions simply by constructing new blocks that don’t contain them.
Let’s say hundreds, or thousands, of stakers do this. How do nodes decide which chain is the right one?
E.g. let’s say I take the main chain, go back to the first block past the latest checkpoint, and remove the competing staking-transactions so that only my staking-transaction is present in that block. The I build on top of this, without competition, because I can selectively remove competing staking transactions simply by constructing new blocks that don’t contain them.
Let’s say hundreds, or thousands, of stakers do this. How do nodes decide which chain is the right one?
If I understand this right, in Casper the right chain is the one in which the least stake is destroyed. In one version, stakers are heavily penalized for going offline, so the chain you describe would destroy a fair amount of stake.
This is Vlad Zamfir's version; Vlad is the lead Casper esearcher, and takes a more long-term theoretical approach, while Vitalik is more focused on near-term practicality. Vitalik's version doesn't penalize dropping offline as heavily; I don't know whether there's some other mechanism to cover this, or he just thinks a lighter penalty is sufficient.
Thanks for the question! Until now I didn't realize the reason for the offline penalty.
This is Vlad Zamfir's version; Vlad is the lead Casper esearcher, and takes a more long-term theoretical approach, while Vitalik is more focused on near-term practicality. Vitalik's version doesn't penalize dropping offline as heavily; I don't know whether there's some other mechanism to cover this, or he just thinks a lighter penalty is sufficient.
Thanks for the question! Until now I didn't realize the reason for the offline penalty.
That was a bit tongue in cheek, it's probably the Foundation. The documentation doesn't specify really how it's done, only that the nodes "authenticate out of band" to determine state when necessary.
There's no key with special privileges. You're probably remembering "weak subjectivity," which is basically an acceptance of things like publicly known checkpoints every now and then. Anyone who's online continually doesn't need to rely on a checkpoint, but in PoS someone new coming in would need it...but this isn't all that different from needing to find out what software they need to run. E.g. Vitalik writes:
"It solves the long-range problems with proof of stake by relying on human-driven social information, but leaves to a consensus algorithm the role of increasing the speed of consensus from many weeks to twelve seconds and of allowing the use of highly complex rulesets and a large state. The role of human-driven consensus is relegated to maintaining consensus on block hashes over long periods of time, something which people are perfectly good at. A hypothetical oppressive government which is powerful enough to actually cause confusion over the true value of a block hash from one year ago would also be powerful enough to overpower any proof of work algorithm, or cause confusion about the rules of blockchain protocol."
https://blog.ethereum.org/2014/11/25/proof-stake-learned-lov...
"It solves the long-range problems with proof of stake by relying on human-driven social information, but leaves to a consensus algorithm the role of increasing the speed of consensus from many weeks to twelve seconds and of allowing the use of highly complex rulesets and a large state. The role of human-driven consensus is relegated to maintaining consensus on block hashes over long periods of time, something which people are perfectly good at. A hypothetical oppressive government which is powerful enough to actually cause confusion over the true value of a block hash from one year ago would also be powerful enough to overpower any proof of work algorithm, or cause confusion about the rules of blockchain protocol."
https://blog.ethereum.org/2014/11/25/proof-stake-learned-lov...
How do you know which checkpoints to trust, unless they are signed?
And if you have trusted checkpoints I fail to see the point of proof-of-stake (or proof-of-anything really). Just call every block a checkpoint and you're done.
Any remaining use cases probably centers around availability, but we know how to build highly available systems and can build them to any degree. Trustless and decentralized systems are much harder.
And if you have trusted checkpoints I fail to see the point of proof-of-stake (or proof-of-anything really). Just call every block a checkpoint and you're done.
Any remaining use cases probably centers around availability, but we know how to build highly available systems and can build them to any degree. Trustless and decentralized systems are much harder.
you also need a developer ecosystem, I prefer any solution, that is fast, secure, and has low fees
What’s this about an “ice age”?
The Ethereum "ice age" is a mechanism to ensure smooth transition to future planned hard forks. By tweaking the difficulty adjustment formula to artificially increase block times after some time (the so called "difficulty bomb") it makes mining on the old chain unprofitable, and incentivizes everyone to move to the/a new one. The general idea is to prevent extreme conservatism and stagnation w.r.t. hard forks, as we are seeing in Bitcoin.
So is this giving the developers the control instead of - as with Bitcoin - the large mining pools? Is that any better?
Incidentally, in Bitcoin, large mining pools do not have control over the consensus rules. It doesn't matter what the miners say, their chain is worthless if people refuse to run it.
In Bitcoin, the economic majority decides what is Bitcoin. And when there's a substantial disagreement (e.g. BCC) there's a fork.
Large mining pools have no more power to enforce consensus rule changes on others than anybody else does.
In Bitcoin, the economic majority decides what is Bitcoin. And when there's a substantial disagreement (e.g. BCC) there's a fork.
Large mining pools have no more power to enforce consensus rule changes on others than anybody else does.
Miners can attack rival chains with the same PoW -- so they do have some extra power over "similar" chains.
[deleted]
The former offers far more visibility than the latter for say in the future.
So yes, IMO it is.
Otherwise private concentration of power will do as it always does: leverage it's monopoly to control the system as a whole.
The discussion & development are in the open. The large mining pools can sit at the table and discuss the changes as a part of the community. Or fork off.
So yes, IMO it is.
Otherwise private concentration of power will do as it always does: leverage it's monopoly to control the system as a whole.
The discussion & development are in the open. The large mining pools can sit at the table and discuss the changes as a part of the community. Or fork off.
As far as I understand there's a build in ice age/difficulty bomb every year so that clients that don't follow the hard fork will essentially stop working. This incentivizes/forces clients to update and also effectively minimizes the chance of a chain split where some group would just keep running on the old chain. If someone wants to make a chain split, they will have to fork too
It's just as easy to create a second hard fork disabling the bomb if some group wants to keep the old rules.
Yes, but that requires some group to agree on this and to run new code, even if it only removes the difficulty bomb. This is not as trivial as you make it out to be, especially because some individuals that may disagree with the 'main' development branch may also still value the difficulty bomb.
It's obvious that this does not prevent disagreement about the protocol, but it greatly affects a fairly large class of disagreements and changes the incentives for a variety of behaviors. It's all game theory, and as such minor changes to the premise of a 'game' can have large impacts on how it plays out.
It's not perfect, but I think it is good.
It's obvious that this does not prevent disagreement about the protocol, but it greatly affects a fairly large class of disagreements and changes the incentives for a variety of behaviors. It's all game theory, and as such minor changes to the premise of a 'game' can have large impacts on how it plays out.
It's not perfect, but I think it is good.
Sure, but it at least prevents the legacy chain from having an advantage due to inertia.
The ice age is a drastic increase in difficulty that was planned at launch to force the developers to release a proof of stake algorithm. The idea was that no one would want to actually switch to a proof of stake when the time came (miners would lose all their profit, and miners have a lot of power - see current bitcoin situation)
To convince early adopters that there would actually be a switch to proof of stake the ice age was conceived. The ice age can be delayed however as we see here (this isn't the first time its been delayed either)
Switching from proof of work to proof of stake will probably be hard to pull off without disruption.
To convince early adopters that there would actually be a switch to proof of stake the ice age was conceived. The ice age can be delayed however as we see here (this isn't the first time its been delayed either)
Switching from proof of work to proof of stake will probably be hard to pull off without disruption.
Hard Forks are the new ICOs. Well, after reading a bit better, this is different, it's unlike BCC and BCG but a change in protocol of the main branch.
Yes, technically it is a Hard Fork (since that is how the code works). But in practice, it is just a network and feature update to Ethereum.
A hard fork with no replay protection, which means that legacy systems which do not upgrade will be vulnerable to sending too much money to third parties. The ethereum devs have chosen to introduce a vulnerability that forces people to upgrade their systems.
4 days! This announcement was made 4 days before the fork is introduced??? Everyone in the whole ecosystem has 4 days to upgrade it be exposed to a vulnerability. If you are running special code or your own client, you have to adjust it for a new block reward, a new script primitive, a difficulty algorithm, and stuff they are literally calling mathemagic.
I don't see how this is responsible development.
4 days! This announcement was made 4 days before the fork is introduced??? Everyone in the whole ecosystem has 4 days to upgrade it be exposed to a vulnerability. If you are running special code or your own client, you have to adjust it for a new block reward, a new script primitive, a difficulty algorithm, and stuff they are literally calling mathemagic.
I don't see how this is responsible development.
Oh come on. Stop FUDing.
1. The fact that there is a hard fork coming has been known for months if not years.
2. Developers have notified the community well in advance and content of the hardfork has been discussed with all key players (ex: reward and difficulty bomb).
3. The development decisions are public as is the process - try searching for live streams of developer meetings where Vitalik and others discuss direction in very democratic fashion. I'm not even interested in those and I came across - funny that you're not aware of the existence.
There is a stark contrast between Eth and BTC where constant bickering is the norm.
1. The fact that there is a hard fork coming has been known for months if not years.
2. Developers have notified the community well in advance and content of the hardfork has been discussed with all key players (ex: reward and difficulty bomb).
3. The development decisions are public as is the process - try searching for live streams of developer meetings where Vitalik and others discuss direction in very democratic fashion. I'm not even interested in those and I came across - funny that you're not aware of the existence.
There is a stark contrast between Eth and BTC where constant bickering is the norm.
> Also, this hardfork seems to have been decided behind closed doors. Where is the mailing list discussion? Where did community members have a chance to raise concerns?
https://github.com/ethereum/EIPs
https://github.com/ethereum/pm/tree/master/All%20Core%20Devs...
These changes should be no surprise to anyone who's made any effort at all to follow Ethereum development.
https://github.com/ethereum/EIPs
https://github.com/ethereum/pm/tree/master/All%20Core%20Devs...
These changes should be no surprise to anyone who's made any effort at all to follow Ethereum development.
We have known about this Hard Fork has been coming for months now. It has been discussed all over the place. This isn't a Hard Fork like the Bitcoin / Bitcoin Cash fork (or Ether Classic). This is the expected change to the network to release new features and another step towards PoS.
- This update was announced almost 2 years ago from the very beginning
- Multiple Discussions in EIPs
- Multiple public dev meetings, with youtube recordings, discussions, etc..
I believe the hard fork was a known thing in the community for a while now.
I had wanted to jump on the ETH hype train and almost bought a bunch but these planned forks make the platform seem very “centralized.”
I had wanted to jump on the ETH hype train and almost bought a bunch but these planned forks make the platform seem very “centralized.”
In some ways it's less centralized than Bitcoin, since there are multiple independent clients, written in different languages. The teams are just good at cooperating.
As with other blockchains, forks don't happen unless users go along with them.
As with other blockchains, forks don't happen unless users go along with them.
It is only a 4 day announcement to you because you chose not to be informed. This change has been discussed and announced for months and development on the features have been planned and discussed for even longer than that.
Just because you chose to not read the announcements doesn't mean it wasn't announced.
Just because you chose to not read the announcements doesn't mean it wasn't announced.
As a user of a piece of infrastructure, I shouldn't have to read Reddit every morning to figure out what's going on. Just like I don't need to follow closely ipv4 development, smtp development, etc.
I'm certain that I'm not the only user who is surprised that the hard fork is only 4 days away.
I'm certain that I'm not the only user who is surprised that the hard fork is only 4 days away.
How would you have preferred to be informed about the fork?
Running a node is more like running an email server, rather than just using email. If you're running a server you should keep up with things.
If, say, you use a hardware wallet and MyEtherWallet to issue your transactions, then you don't have any updates to make.
If, say, you use a hardware wallet and MyEtherWallet to issue your transactions, then you don't have any updates to make.
FWIW this has been a long while in the making and not a surprise to anyone
Maybe it is not responsible, but it is certainly agile. :)
Do you need to do anything if you own ETH?
No. Node owners will upgrade, including exchanges.
Update your wallet (if you use Mist or Wallet) before making any transactions.
It is an expected fork, basically an upgrade to the network that isn't going to result in a new coin (in practice - technicalities excluded.)
It is an expected fork, basically an upgrade to the network that isn't going to result in a new coin (in practice - technicalities excluded.)
Hopefully we wont see ethereum gold
Steem blockchain hardfork 19 times monero hardfork every 6 months both are decentralize no vitalik no problem
Steem blockchain hardfork 19 times monero hardfork every 6 months both are decentralize no vitalik no problem
IMHO such planned improvements shouldn't be called hard forks, it's a kind misleading for folks outside cryptocurrencies.
But it is a hard fork, termed that way by the organization that is the custodian of the ethereum network. It is only misleading if people outside cryptocurrencies misrepresent what a hard fork means.
Ethereum foundation is not the custodian of the network. This is a debatable point, since it's not perfectly clear what that would mean. Ethereum Foundation doesn't own the miners or the validating nodes on the network, and can't control who joins or what software they run. Like other development teams, they can propose and try to drum up support for upgrades, which they've been successful at so far.
Detractors of Ethereum would prefer to view the Foundation as having much greater influence over the network, since that would mean it's less centralized. Proponents of Ethereum on the other hand would say Ethereum Foundation's role is similar to that of Bitcoin Core, except the divisiveness hasn't set in yet (or in the case of Ethereum Classic, opposing factions split off before it got bad).
Detractors of Ethereum would prefer to view the Foundation as having much greater influence over the network, since that would mean it's less centralized. Proponents of Ethereum on the other hand would say Ethereum Foundation's role is similar to that of Bitcoin Core, except the divisiveness hasn't set in yet (or in the case of Ethereum Classic, opposing factions split off before it got bad).
The Ethereum Foundation owns and controls the trademarks of Ethereum. While they cannot dictate the code the various participants on the network run, they get to explicitly decide which version of the code gets to be called "Ethereum". That's how they maintain control.
There's a good chance that the trademark is no longer enforceable due to their failure to apply enforce it against Ethereum Classic. There has been quite a bit of discussion about this within the community.
Who should they have sued to enforce their trademark in the case of Ethereum Classic? Unless the argument is for genericization as opposed to failure to enforce, I don't understand.
The also own a lot of eth, directly and through their members private holdings. Keep in mind that Ethererum is mostly pre-mined.
Slight gripe: I'm pretty sure they own a lot of validating nodes.
Maybe calling it a "preplanned hardfork" is the better idea then, as that seems to be a critical difference.
Very much agree. Hard fork has the implication of people disagreeing to the point where two things go in the opposite direction. Whereas this is just improvement for the future. Using the term hard fork is fine, but throw "update" in the phrase to make it sound positive.
I mean, you argument is that we should all lie about what the "upgrade/hardfork" is, because the truth could cause controversy.
This change is not backward compatible. Therefore it is a hardfork. Full stop.
This change is not backward compatible. Therefore it is a hardfork. Full stop.
I think it's not about lying, but very often software upgrades are not backward compatible, in that case, everybody should upgrade, that's all. It is probably more intuitive concept for the mainstream market than saying "a hard fork is coming soon".
To many familiar with open source, "fork" implies some sort of intractable difference: personality, legal, technical decision, etc. "Incompatible change" seems more accurate, at least based on terms I'm used to hearing.
This is quite clear terminology in cryptoworld, although I can understand why people are a bit confused with the events that unfolded in August. A hard fork is any fork where new nodes produce blocks that old nodes do not accept (and vice versa). A soft fork is one where new nodes produce blocks that old nodes accept, but not the other way around (e.g. new nodes reject blocks made by old nodes). That's it.
So this _is_ a hard fork, albeit not a very contentious one. And it _will_ result in a chain split, with the minority chain probably having low activity/worth due to (1) lack of support (2) the ice age which will increase block times to slowly kill it (and that it itself has to be hard forked to stay alive).
So this _is_ a hard fork, albeit not a very contentious one. And it _will_ result in a chain split, with the minority chain probably having low activity/worth due to (1) lack of support (2) the ice age which will increase block times to slowly kill it (and that it itself has to be hard forked to stay alive).
“Hard fork” has a precise technical definition.
(Which is that if all nodes don't upgrade, a chain fork will occur)
Although not guaranteed, a soft fork can still result in a (lasting) chain split. Especially in the case of Bitcoin (which has slow difficulty adjustment), if the hash rate of the SegWit miners was lower than that of the old miners, the legacy chain could have easily prevailed/survived. It's a game of chance (read: race) right after the fork though, with the new nodes "winning" as soon as they generate a longer chain than the old nodes. This becomes ever more likely of course with a higher percentage of the combined hash rate.
Could this result in ETH splitting up into two currencies again, like it did last year? If so, there will be tax consequences / realized gains for those who sell out of the version they don't want to hold... further complicating things.
Almost certainly not. The expected outcome is that everyone will update their software, and the old fork will die.
Unlike last year this is not a controversial fork. It's just a planned part of the network upgrade process. No groups are planning to boycott the fork.
(It's futher enforced by code in the old fork that will cause it to die shortly, so even if a group of people wanted to keep running the old fork, they would actually have to hard fork it themselves to remove the 'ice age' anyway. So it would have to be a concious act, rather than just people forgetting to upgrade)
Unlike last year this is not a controversial fork. It's just a planned part of the network upgrade process. No groups are planning to boycott the fork.
(It's futher enforced by code in the old fork that will cause it to die shortly, so even if a group of people wanted to keep running the old fork, they would actually have to hard fork it themselves to remove the 'ice age' anyway. So it would have to be a concious act, rather than just people forgetting to upgrade)
Agreed, "schism" is a better term in this instance
> After the fork, eth.getTransactionReceipt(…) will return a status field. The status field has a value of 0 when a transaction has failed and 1 when the transaction has succeeded.
I wonder why they chose to do it the wrong way around...
I wonder why they chose to do it the wrong way around...
It's a status field, not an error code. 0 = False, 1 = True seems like the right way to do things.
But why not return a proper Boolean value then?
Thats how booleans are encoded in the Ethereum ABI. 0x0 is false, 0x1 is true.
Who knows, maybe for legacy code reasons? This seems to be the documentation: https://github.com/ethereum/wiki/wiki/JSON-RPC#eth_gettransa...
Can anyone explain what "proof of stake" actually is? My understanding is that it's a virtualized/simulated proof of work system.
In proof of stake a single node decides what the next block added to chain is. This node gets the block reward and any transaction fees. They don't have to do any calculations, they simply get to decide, according to a set of rules, which transactions are in the next block. (Ethereum complicates this a bit by having multiple nodes "bet" which blocks will be accepted, instead of just one node choosing the block)
In order to decide who gets to be this node, people Stake coins. The probability that you are the chosen node is proportional to the number of coins you have staked. If you are chosen, and you do something against the rules, like double spend coins and try and add this to the next block, then you lose your staked coins.
So instead of rewards being proportional to hashing power, they are proportional to staked coins.
This is still being tested, but it's going pretty well.
In order to decide who gets to be this node, people Stake coins. The probability that you are the chosen node is proportional to the number of coins you have staked. If you are chosen, and you do something against the rules, like double spend coins and try and add this to the next block, then you lose your staked coins.
So instead of rewards being proportional to hashing power, they are proportional to staked coins.
This is still being tested, but it's going pretty well.
> This is still being tested, but it's going pretty well.
AIUI, there isn't consensus today that proof of stake is actually workable.
https://en.wikipedia.org/wiki/Proof_of_stake#Criticism
AIUI, there isn't consensus today that proof of stake is actually workable.
https://en.wikipedia.org/wiki/Proof_of_stake#Criticism
Reminds me of the UK government's premium bonds
"Proof of work" proves that you have performed some calculations. "Proof of stake" proves that you have a certain number of tokens.
[edit] The whole idea of each is to make sock-puppeting when voting on the truth unprofitable.
With the first, you need a near majority of the compute power in the network to have people believe your "lie" with the second you need a near majority of the coins in the network to do so.
[edit2]
Imagine that banks don't exist, instead everyone writes down every transaction that happens. Then at the end of the day we all get together in the village square and vote on who has what money. This would make it so that no minority of the village can steal money from anyone else.
We can't do that with bitcoin &c. because how do you prevent one person from just running a billion bitcoin clients and voting all the money to themselves? So instead bitcoin (very roughly speaking) requires you to prove that you have done some work to get to vote on what the ledger looks like. This is proof of work. If instead it were "one dollar, one vote" that would be proof of stake.
[edit] The whole idea of each is to make sock-puppeting when voting on the truth unprofitable.
With the first, you need a near majority of the compute power in the network to have people believe your "lie" with the second you need a near majority of the coins in the network to do so.
[edit2]
Imagine that banks don't exist, instead everyone writes down every transaction that happens. Then at the end of the day we all get together in the village square and vote on who has what money. This would make it so that no minority of the village can steal money from anyone else.
We can't do that with bitcoin &c. because how do you prevent one person from just running a billion bitcoin clients and voting all the money to themselves? So instead bitcoin (very roughly speaking) requires you to prove that you have done some work to get to vote on what the ledger looks like. This is proof of work. If instead it were "one dollar, one vote" that would be proof of stake.
So that's basically the original proof-of-stake design. People figured out various ways to attack it (at least in theory, I don't think there's been a successful attack in the wild).
Ethereum's version is a bit different: to stake, you have to lock up your ETH for at least four months. Then you have your node start betting your staked ETH on which blocks will be accepted by the network. The blocks which are accepted are the ones that get the most stake-weighted bets.
You start with low-confidence votes that won't lose much when you're wrong, see what everybody else does, and progress to high-confidence votes that pay off better when you're right. There's a little bit of inflation plus transaction fees so it's not a zero-sum game, and it all converges on finalized blocks.
This is somewhat analogous to mining; if there's more than one finalized block available, miners have to pick one to build on, essentially betting their electricity on which block will be accepted by everyone else.
Here's an interesting FAQ:
https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQ
Ethereum's version is a bit different: to stake, you have to lock up your ETH for at least four months. Then you have your node start betting your staked ETH on which blocks will be accepted by the network. The blocks which are accepted are the ones that get the most stake-weighted bets.
You start with low-confidence votes that won't lose much when you're wrong, see what everybody else does, and progress to high-confidence votes that pay off better when you're right. There's a little bit of inflation plus transaction fees so it's not a zero-sum game, and it all converges on finalized blocks.
This is somewhat analogous to mining; if there's more than one finalized block available, miners have to pick one to build on, essentially betting their electricity on which block will be accepted by everyone else.
Here's an interesting FAQ:
https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQ
Thank you for this short and clear synopsis. I had gathered some fragments on how the 'nothing at stake' problem was supposedly solved, but this lays it out very clearly.
[deleted]
In theory, it means that if minerA has 100 coins, and minerB has 1 coin, minerB will need 100x the hash power to mine the same amount of blocks as minerA on average. Not sure how the implementation is done in Ethereum, but I imagine it involves easier challenges if you sign with a wallet that contains X coins.
Will this lead to a new coin, or is everybody in agreement this time?
Also, what's the plan for ETC, will that also hard fork?
Also, what's the plan for ETC, will that also hard fork?
I wonder if the planned switch to proof-of-stake is ever going to happen.
In any case, what's the point of continuously postponing a pre-programmed difficulty bomb (via a hard for), when miners can just remove this part from the code and continue with that fork if they wish? Because of this, it seems like it doesn't do much difference compared to just switching to PoS via a hard fork whenever it's ready. I mean, if miners really want to continue with PoW, removing those couple of lines, that define the difficulty time bomb, from the Ethereum code surely won't be a problem, right?