• The Purpose of Mining

• A transaction is made and included with other transactions in a Block;
  
• Miners verify every transaction in the block are legitimate;
  
• In order to do this they must solve a mathematical problem;
  
• Rewards are handed out to the miner that successfully solved the problem;
  
• All legitimate transactions are stored in the mined block on the blockchain.
  

Quote:Imagine 100 people sitting around a circular table. One person has a bundle of papers, each with a different transaction history. The first participant picks up a pen and signs one, then passes it onto the next person, who makes a similar choice.

Each participant only gets $1 if they sign the transaction history that most of the participants sign in the end. And if you sign one page and later sign a different page, your house burns down.

• Cheaper. There will no longer be a need for hardware and electricity costs.
  
• Less Censored. Unlike Proof of Work blockchains, Ethereum plans on providing solutions for a more censor-friendly blockchain.
  
• Scalable. Ethereum will become more more scalable allowing larger applications.
  

• Casper & The Casper Contract

• Hardware Mining will no longer exist. Virtual mining and validators will take its place. To become a validator, you must lock up some ETH for a specific amount of time, currently set for 4 months.
  
• Lower Latency. Block times will become super fast. Ethereum developer Vlad Zamfir believes it can start at 4 seconds/block and be pushed down to 1 second/block.
  
• Finality. Ethereum will be able to quickly prove who owns what and how many. This will make it impossible for a random blockchain glitch to suddenly decide that the operation that made those assets theirs is now reverted and so their ownership claim over those assets is lost.
  

• Key Changes

• Mining will no longer exist in a sense. Hardware mining will disappear. Mining will now be conducted in the form of validating.
  
• Proof of Stake and the absence of miners mean less coins coming into supply. Inflation will now be initiated.
  
• Total ETH supply will be around 100M. Target ETH at stake is 10M. Target ROI for validators is 8%; therefore, the annual inflation will be around 0.8%.
  
• Block times will start around 1 block/4 seconds and eventually become 1 block/second.
  

(Jun 12, 2017 06:25 PM)Sin+ Wrote:  I haven't read too much up on the PoS system, but whats to combat if I hypothetically have control of a large amount of validators?

Quote:Imagine 100 people sitting around a circular table. One person has a bundle of papers, each with a different transaction history. The first participant picks up a pen and signs one, then passes it onto the next person, who makes a similar choice.

Each participant only gets $1 if they sign the transaction history that most of the participants sign in the end. And if you sign one page and later sign a different page, your house burns down.

(Jun 12, 2017 06:31 PM)Kill Joy Wrote:  This is combated by the Casper Protocol. So far it is planned to have only 250 validators at any given time. Validators will want to follow the rules or they will be punished and lose their own money.

Example by Vitalik Butener:


Since it is early and there hasn't been a development post in a couple months, we can look forward to even more assurance that validators cannot be abused.

(Jun 12, 2017 06:29 PM)abc123xD Wrote:  Will this affect transaction fees at all?

(Jun 12, 2017 06:35 PM)Sin+ Wrote:  Yeah, but what if the majority of the validators are owned by me, and I have them "sign papers" of my choosing? I'm just a little confused on the specifics that would actually combat this. I mean, how would you know I was breaking the rules, if I make up the majority?

Quote:What would the equivalent of a 51% attack against Casper look like?

The most basic form of "51% attack" is a simple finality reversion: validators that already finalized block A then finalize some competing block A', thereby breaking the blockchain's finality guarantee. In this case, there now exist two incompatible finalized histories, creating a split of the blockchain, that full nodes would be willing to accept, and so it is up to the community to coordinate out of band to focus on one of the branches and ignore the other(s).

This coordination could take place on social media, through private channels between block explorer providers, businesses and exchanges, various online discussion forms, and the like. The principle according to which the decision would be made is "whichever one was finalized first is the real one". Another alternative is to rely on "market consensus": both branches would be briefly being traded on exchanges for a very short period of time, until network effects rapidly make one branch much more valuable with the others. In this case, the "first finalized chain wins" principle would be a Schelling point for what the market would choose. It's very possible that a combination of both approaches will get used in practice.

Once there is consensus on which chain is real, users (ie. validators and light and full node operators) would be able to manually insert the winning block hash into their client software through a special option in the interface, and their nodes would then ignore all other chains. No matter which chain wins, there exists evidence that can immediately be used to destroy at least 1/3 of the validators' deposits.

Another kind of attack is liveness denial: instead of trying to revert blocks, a cartel of >=34% of validators could simply refuse to finalize any more blocks. In this case, blocks would never finalize. Casper uses a hybrid chain/BFT-style consensus, and so the blockchain would still grow, but it would have a much lower level of security. If no blocks are finalized for some long period of time (eg. 1 day), then there are several options:

The protocol can include an automatic feature to rotate the validator set. Blocks under the new validator set would finalize, but clients would get an indication that the new finalized blocks are in some sense suspect, as it's very possible that the old validator set will resume operating and finalize some other blocks. Clients could then manually override this warning once it's clear that the old validator set is not coming back online. There would be a protocol rule that under such an event all old validators that did not try to participate in the consensus process take a large penalty to their deposits.
A hard fork is used to add in new validators and delete the attackers' balances.
In case (2), the fork would once again be coordinated via social consensus and possibly via market consensus (ie. the branch with the old and new validator set briefly both being traded on exchanges). In the latter case, there is a strong argument that the market would want to choose the branch where "the good guys win", as such a chain has validators that have demonstrated their goodwill (or at least, their alignment with the interest of the users) and so is a more useful chain for application developers.

Note that there is a spectrum of response strategies here between social coordination and in-protocol automation, and it is generally considered desirable to push as far toward automated resolution as possible so as to minimize the risk of simultaneous 51% attacks and attacks on the social layer (and market consensus tools such as exchanges). One can imagine an implementation of (1) where nodes automatically accept a switch to a new validator set if they do not see a new block being committed for a long enough time, which would reduce the need for social coordination but at the cost of requiring those nodes that do not wish to rely on social coordination to remain constantly online. In either case, a solution can be designed where attackers take a large hit to their deposits.

A more insidious kind of attack is a censorship attack, where >= 34% of validators refuse to finalize blocks that contain certain kinds of transactions that they do not like, but otherwise the blockchain keeps going and blocks keep getting finalized. This could range from a mild censorship attack which only censors to interfere with a few specific applications (eg. selectively censoring transactions in something like Raiden or the lightning network is a fairly easy way for a cartel to steal money) to an attack that blocks all transactions.

There are two sub-cases. The first is where the attacker has 34-67% of the stake. Here, we can program validators to refuse to finalize or build on blocks that they subjectively believe are clearly censoring transactions, which turns this kind of attack into a more standard liveness attack. The more dangerous case is where the attacker has more than 67% of the stake. Here, the attacker can freely block any transactions they wish to block and refuse to build on any blocks that do contain such transactions.

There are two lines of defense. First, because Ethereum is Turing-complete it is naturally somewhat resistant to censorship as censoring transactions that have a certain effect is in some ways similar to solving the halting problem. Because there is a gas limit, it is not literally impossible, though the "easy" ways to do it do open up denial-of-service attack vulnerabilities.

This resistance is not perfect, and there are ways to improve it. The most interesting approach is to add in-protocol features where transactions can automatically schedule future events, as it would be extremely difficult to try to foresee what the result of executing scheduled events and the events resulting from those scheduled events would be ahead of time. Validators could then use obfuscated sequences of scheduled events to deposit their ether, and dilute the attacker to below 33%.

Second, one can introduce the notion of an "active fork choice rule", where part of the process for determining whether or not a given chain is valid is trying to interact with it and verifying that it is not trying to censor you. The most effective way to do this would be for nodes to repeatedly send a transaction to schedule depositing their ether and then cancel the deposit at the last moment. If nodes detect censorship, they could then follow through with the deposit, and so temporarily join the validator pool en masse, diluting the attacker to below 33%. If the validator cartel censors their attempts to deposit, then nodes running this "active fork choice rule" would not recognize the chain as valid; this would collapse the censorship attack into a liveness denial attack, at which point it can be resolved through the same means as other liveness denial attacks.

(Jun 12, 2017 06:39 PM)OnlyProfit Wrote:  Don't get me wrong guys. I've read this through. To me its seems like PoW is much better for regular people like me and you as it seems like everyone has the same power if you can call it that. While PoS seem's like its like a banking system. Where 1 bank regulate's all transactions. I don't like this idea AT ALL. Unless i get something wrong here.

(Jun 12, 2017 06:46 PM)IPIKIN Wrote:  Why won't we be able to mine ETH once it goes to POS?

(Jun 12, 2017 06:47 PM)TheBanker Wrote:  Alright so after reading through this info here is what I gather. Please someone correct me if I am wrong.

-The speed of "confirming" transactions will be quicker and more secure.
-The current state of mining will go away.
-The fees could see a reduction from where they are now for ETH transactions.

Am I reading this correctly?

(Jun 12, 2017 06:58 PM)Tren Ace Wrote:  When you say only 250 validators, does that mean only 250 are eligible to gain ETH on what they stake?