Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EIP-1011 -- Hybrid Casper FFG #5

Open
djrtwo opened this issue Apr 20, 2018 · 65 comments

Comments

@djrtwo
Copy link
Owner

commented Apr 20, 2018

EIP 1011

Change Log

  • [2018/05/16]
    • Expand and update glossary
    • Change name of SIGHASHER to MSG_HASHER
    • Initialize casper contract with an explicit CALL to init rather than with a constructor in EVM init code.
    • Remove vote_gas_limit. Add vote_gas_used and clarify gas_used in vote transaction receipts
    • Update fork choice to include full pseudocode. New pseudocode utilizes casper contract fork choice helpers -- highest_justied_epoch(min_deposits) and highest_finalized_epoch(min_deposits)
    • add param INITIALIZE_EPOCH_BYTES to more clearly define the previous 0x5dcffc17 magic number
    • add param VOTE_BYTES to help clients filter transactions for vote transactions
    • add param WARM_UP_PERIOD to provide a stretch of blocks for validators to initially deposit before FFG functionality begins.
    • add reference to casper.slashable(vote_1, vote_2) contract helper method in --monitor-votes
  • [2018/05/05]
    • add note about the conditions under which the PoW and hybrid fork choice would diverge
    • add spec to step down miner rewards over a ~12 month period
    • add --monitor-votes client setting and slashing pseudocode
    • add discussion of miner vote tx incentives, update CASPER_BALANCE to 1.25M to account for miner vote issuance in the estimated funding crunch
    • introduce vote_gas_limit and discussion
    • fix typos
  • [2018/04/24]

@djrtwo djrtwo changed the title Discussion related to EIP-1011 -- Hybrid Casper FFG EIP-1011 -- Hybrid Casper FFG Apr 20, 2018

@atlanticcrypto

This comment has been minimized.

Copy link

commented Apr 20, 2018

@djrtwo so does this mean that the block reward reduction is arbitrary? My question was specifically about the 50 block window, understanding that the finality aspect reduced the risk.

What work has been done to assess the risk reduction?

@djrtwo

This comment has been minimized.

Copy link
Owner Author

commented Apr 23, 2018

My apologies for the slow reply @Njcrypto. I was AFK most of the weekend.

This is an excellent question and one we have been concerned about too. I am compiling our analysis into a blog post to share shortly.

@djrtwo

This comment has been minimized.

Copy link
Owner Author

commented Apr 24, 2018

@Njcrypto Here is our current analysis: https://gist.github.com/djrtwo/bc864c0d0a275170183803814b207b9a

@RadixPi

This comment has been minimized.

Copy link

commented Apr 24, 2018

I think it's important to compare this PoW reward reduction with the one that happened last year. There were 3 events that mitigated the previous 40% (5->3 eth/blk) reduction:

  • The "ice age" had already come into effect and the reduction reset the difficulty bomb. The combination of these meant that the ETH/day decreased somewhat smoothly from ~32k -> ~18k over the span of 6 months: https://etherscan.io/chart/ethersupply
  • The price was rising drastically - going up roughly 4x in the same time. So while the ETH/day was decreasing the USD/day was increasing.
  • The hashrate was increasing drastically in response to the USD/day increase - going up roughly 5x in the same time. So instead of reducing hashrate the reduction (temporally) prevented an even larger increase in hashrate.

In this case there's no difficulty bomb in effect. The price and hashrate have been relatively stable (as far as cryptos go) over the past few months. Assuming these conditions hold there won't be anything to mitigate the drastic, 80% drop in PoW reward.

I see 2 significant problems with a step-function 3->0.6 reduction:

  • The EIP suggests that clients initially default to the Casper fork choice disabled. This means the network will be entirely reliant on PoW security, yet that security will have just been thrown into disarray by a huge reward reduction. This transition period will be ripe for attack.
  • The reduction could make 50% of the hashrate no longer profitable to mine Eth. It could be more profitable for a significant portion of this hashrate, that's already been bought and paid for, to attack the network instead of mining conventionally (either another coin or eth at much lower reward).

I strongly suggest that the PoW reduction is phased, say over 12 months. That will allow for an orderly transition from being entirely dependent on PoW security to hybrid PoW/PoS security. This also allows for a safety fallback if there are any issues with PoS that prevent the Casper fork choice from being enabled for a while.

@gumb0

This comment has been minimized.

Copy link

commented Apr 27, 2018

"Fork Choice" segment of the EIP is not really clear to me, I'd like to clarify it and ideally have in the end some kind of pseudo-code for how the client should behave, taking into account all the rules and runtime client settings.

So my current understanding is something like this. The following fork choice logic is in effect at the moment when we add the new valid block into the blockchain and we'd like to determine whether the new block is the new chain head.

def is_new_head(new_block):
    if --casper-fork-choice is off
        return new_block.total_difficuty > current_head.total_difficulty

    if new_block is in --exclude list or one of its descendants 
        return false

    # don't revert finalized blocks
    if block is in last_finalized_epoch or older
        return false

    return new_block.highest_justified_epoch * 10**40 + new_block.total_difficuty > 
        current_head.highest_justified_epoch * 10**40 + current_head.total_difficulty

Now what is unclear:

  • how exactly do we determine last_finalized_epoch? Do we ask Capser contract for it (it has public variable of this name)? If yes, at which state exactly, at the end of current_head block?
  • how do we get new_block.highest_justified_epoch and current_head.highest_justified_epoch? Do we ask Capser contract for it?
  • at which moment is NON_REVERT_MIN_DEPOSIT considered?
@jacob-eliosoff

This comment has been minimized.

Copy link

commented Apr 28, 2018

@RadixPi's comment makes sense to me. Aside from lower total issuance and a bit of simplicity, what are the advantages of a sudden reward drop? "Phased rather than sudden" seems like it should be the default way to change such critical values.

@jacob-eliosoff

This comment has been minimized.

Copy link

commented Apr 28, 2018

Another question: what would be the quickest & least painful way to revert from Casper FFG back to regular pre-HF PoW, in case of one of various severe failures (in the protocol code, the Casper contract, economic behavior, ...)?

Worth having a reversion plan, and even designing around it where practical. Eg, this might be another point in favor of gradual rather than sudden reward changes.

@ChihChengLiang

This comment has been minimized.

Copy link

commented Apr 28, 2018

@gumb0 we all have to ask contract for it. And the NON_REVERT_MIN_DEPOSIT is considered before determining a finalized block, as shown in this example.

@quantumproducer

This comment has been minimized.

Copy link

commented Apr 29, 2018

Am I reading this correct that 1500 ETH is required to gain benefits from staking:

MIN_DEPOSIT_SIZE is set to 1500 ETH to form a natural upper bound on the total number of validators, bounding the overhead due to vote messages.

With current GDAX prices, that means everyone who isn't literally a millionare from ETH can't stake.

@jacob-eliosoff

This comment has been minimized.

Copy link

commented Apr 29, 2018

My understanding is that communications overhead from voting puts a ceiling on the number of stakers, which means the minimum stake has to be quite high. But note that staking pools are definitely part of the plan and should support much lower deposits. One example I've heard about is https://www.rocketpool.net/, with planned minimum deposit 0.1 ETH (<$100): https://medium.com/rocket-pool/rocket-pool-101-faq-ee683af10da9

A big part of PoS's appeal to people like me is the hope that it will reduce the barrier to entry of PoW mining. Right now to start profitably mining on a mature PoW network like Bitcoin costs >$5k. I'm optimistic that Casper staking pools will make profitable staking possible for <5% of that.

@djrtwo

This comment has been minimized.

Copy link
Owner Author

commented Apr 30, 2018

@RadixPi @jacob-eliosoff I hear your concerns and am discussing the potential complexities in altering the design and tradeoffs with the research team. Hoping to have a response to you in a couple of days.

Fortunately, this issuance design is peripheral to the core FFG so we can keep this dialogue open as clients begin and continue to implement.

@djrtwo

This comment has been minimized.

Copy link
Owner Author

commented Apr 30, 2018

@quantumproducer, @jacob-eliosoff is correct. The minimum helps bound the overhead from the messages sent from the protocol. Casper votes can be processed in parallel with normal block messages, but the complexity of the casper votes cannot exceed that of normal block messages or else this would be in effect exceeding the gas limit.

Pools can and will be in effect to open up access to a larger portion of validators. We except to see many different types of pools and structures utilizing contracts and novel validator signing schemes. Currently, we are implementing "soft" or "partial" slashing which will encourage smaller pools. The larger the total stake that commits a slashing condition in a given period, the higher portion of at fault validator funds are slashed. If you are in a small pool and your pool commits a slashing condition by accident and no one else on the network at that time commits a slashing condition, then you will only lose a small amount of money. If instead you are in a mega pool and your pool commits a slashing condition, you will lose a proportionally higher amount of eth due to the penalty because a larger portion of the network was at fault.

@djrtwo

This comment has been minimized.

Copy link
Owner Author

commented Apr 30, 2018

@gumb0 Thank you for taking the time to dig into the EIP. I agree we should have a full and clear pseudocode for the fork choice. I realized when trying to write a succinct version of the pseudocode, that it will be much simpler for client implementations if we have the contract memoize the size of deposits related to each potential checkpoint.

And to follow the general design principle of including as much complexity in the contract to reduce complexity to replicate across clients, I'm making these changes to the contract before I finish the pseudocode. I'll ping you when it's ready.

@quantumproducer

This comment has been minimized.

Copy link

commented May 1, 2018

@jacob-eliosoff interesting, you believe proof of work mining becomes more profitable, because of the payouts? I've heard from a few miners that they have been dreading Casper because they forsee less profit from mining.

@jacob-eliosoff

This comment has been minimized.

Copy link

commented May 1, 2018

@quantumproducer No. Casper (the future full-PoS version, not this hybrid version) is bad for PoW miners. What I meant was that Casper validators should have less of a tendency to centralize over time than PoW miners.

PoW mining (for most hash functions anyway) has the property than a 10x-larger investment earns you more than 10x the returns. This has the centralizing effect that large miners are more profitable (as a %), and smaller miners get squeezed out. In Casper this effect should be much smaller: 10x the stake gives ~10x the returns.

@quantumproducer

This comment has been minimized.

Copy link

commented May 1, 2018

@jacob-eliosoff

This comment has been minimized.

Copy link

commented May 1, 2018

Eventually. My guess is sharding will hit production months/years after Casper (but what do I know). So in the interim, we'll have to live with Casper-w/o-sharding's 1500 ETH (or whatever) minimum.

@jacob-eliosoff

This comment has been minimized.

Copy link

commented May 1, 2018

@djrtwo On reversion plans - would it be conceivable to make (hybrid) Casper only kick in if there are enough stakers, such that if enough of them withdraw/drop off, it just seamlessly reverts back to pure PoW? This wouldn't handle all reversion cases (eg, if Casper was broken in a way that incentivized stakers to keep staking), but it would handle some of them very cleanly.

(I guess NON_REVERT_MIN_DEPOSIT is kinda related to this? But that defines the client's finalization threshold, rather than the network-wide threshold for PoS to be active, right?)

More generally, seems like it should be doable to release hybrid Casper in such a way that, if the community wants to revert the network to pure-PoW, it can do so without needing any new code. (If not via stakers-stopping-staking, then perhaps via a command-line flag, etc)

@gumb0

This comment has been minimized.

Copy link

commented May 4, 2018

Do not count gas of vote toward the block gas limit

Just to make sure: this concerns the values of cumulative gasUsed in the vote transactions' receipts, doesn't it? That is for all vote receipts gasUsed is equal and equal to last non-vote receipt.

@gumb0

This comment has been minimized.

Copy link

commented May 4, 2018

All unsuccessful vote transactions to CASPER_ADDR are invalid and must not be included in the block

Does this mean I can attack the nodes by sending out valid-looking blocks, consisting of valid transactions followed by a transaction with unsuccessful vote, and the nodes will need to execute this whole block before they understand it's invalid, but no gas will be charged for this?

@gumb0

This comment has been minimized.

Copy link

commented May 4, 2018

checkpoint: The start block of an epoch. Rather than dealing with every block, Casper FFG only considers checkpoints for finalization.

Basic question: so which blocks are considered finalized? The blocks for all epochs before the checkpoint?
(this is a little confusing, because the checkpoint is the start of an epoch, so then other blocks of an epoch with finalized checkpoint are still not finalized, right?)

@holgerd77

This comment has been minimized.

Copy link

commented May 4, 2018

Hi @djrtwo, today I found some time to do an EIP review from an implementers perspective, here are some notes for the first round (will post again once I continue):
https://docs.google.com/document/d/1eyJ7aXZgvNdhzprqTwQQBlLCynaWFJ5qFlPqb5vwT_E/edit?usp=sharing

@djrtwo

This comment has been minimized.

Copy link
Owner Author

commented May 5, 2018

@gumb0 The casper contract now memoizes deposit sizes for each checkpoint and I added a couple of helper functions for clients. The fork choice rule pseudocode is much simpler :)

The pseudocode can be found here for your (and anyone else's) review before we integrate it into the EIP.

@djrtwo

This comment has been minimized.

Copy link
Owner Author

commented May 5, 2018

In response to your other questions @gumb0:

Just to make sure: this concerns the values of cumulative gasUsed in the vote transactions' receipts, doesn't it? That is for all vote receipts gasUsed is equal and equal to last non-vote receipt.

Yes, do you think the spec should have a clarification on this?

Does this mean I can attack the nodes by sending out valid-looking blocks, consisting of valid transactions followed by a transaction with unsuccessful vote, and the nodes will need to execute this whole block before they understand it's invalid, but no gas will be charged for this?

For a miner to perform this attack, they would actually need to use computational power to successfully mine the block. Otherwise, the hash would would be invalid and clients would just reject the block outright. I don't think we can consider this a DoS vector because of the insane cost to do so. If say an attacker has 20% of the network's hashing power, they could create invalid blocks such that approximately 1 out every 5 blocks is invalid causing a minor hinderance to node's processing blocks at the cost of forgoing mining rewards. The cost is very asymmetrically against the attacker. If instead, the attacker as a larger portion of mining rewards say >51%, they could do much more nefarious things than sending invalid mined blocks around.

Basic question: so which blocks are considered finalized? The blocks for all epochs before the checkpoint?

When a block is considered finalized, all previous blocks are implicitly finalized. My definition of checkpoint is actually off. A checkpoint is actually the last block of the previous epoch. For example, the checkpoint for the 100th epoch is actually block 4999 (100 * 50 - 1). I'll fix this and also make it clearer that all blocks prior to a finalized block are finalized.

@jacob-eliosoff

This comment has been minimized.

Copy link

commented May 5, 2018

When a block is considered finalized, all previous blocks are implicitly finalized. My definition of checkpoint is actually off. A checkpoint is actually the last block of the previous epoch. For example, the checkpoint for the 100th epoch is actually block 4999 (100 * 50 - 1). I'll fix this and also make it clearer that all blocks prior to a finalized block are finalized.

Ugh, is that really necessary? To me it feels much more intuitive for the 50th epoch to consist of blocks 4901-5000, and be finalized by its checkpoint, block 5000. Not the end of the world of course, cosmetic issue, but these details are certainly critical and it's usually safer to make code conform to intuition rather than other way round.

The "directly finalized" vs "implicitly finalized" distinction makes sense to me. As I understand it, non-checkpoint blocks are only ever implicitly finalized, when a checkpoint after them is finalized. A checkpoint block may be finalized either directly (by the Casper contract) or implicitly (like a non-checkpoint block - because a later checkpoint block was directly finalized).

@djrtwo

This comment has been minimized.

Copy link
Owner Author

commented May 5, 2018

@Njcrypto @RadixPi @jacob-eliosoff I hear you and agree with you that stepping miner rewards down is a more conservative approach in our transition to hybrid PoS for many reasons. The relative PoW analysis is still relevant to the magnitude of the eventual drop, but we will now more smoothly get there over the course of ~12 months. Thank you all for your input and insight :)

Check out the updated EIP for details. Also see above for the changelog of other recent updates

@jacob-eliosoff

This comment has been minimized.

Copy link

commented May 5, 2018

@holgerd77 One of your points @djrtwo already answered for me: dynasties vs epochs. "The withdrawal_delay and dynasty_logout_delay are in different units (epochs and dynasties) respectively because they serve different purposes. The key difference between an epoch and a dynasty is that epochs increment no matter what, whereas a dynasty only increments when an epoch is finalized." So, eg, if 5 epochs go by without finalization, and then the 6th is (explicitly!) finalized, then the epoch number has increased by 6, but the dynasty number only by 1.

On a related note - this line in the EIP:

dynasty: The number of finalized checkpoints in the chain from root to the parent of a block.

would probably be clearer as:

dynasty: The number of explicitly [or directly?] finalized checkpoints in the chain from root to the parent of a block.

@atlanticcrypto

This comment has been minimized.

Copy link

commented May 5, 2018

@djrtwo Awesome news. That will allow the market to more smoothly discount the change and will keep security enhanced as the early stages of the roll-out occur. Kudos to the development team.

@gumb0

This comment has been minimized.

Copy link

commented May 11, 2018

@djrtwo Thank you for clarifications, here's one more question

--join-fork BLOCKHASH where the client automatically sets the head to the block defined by BLOCKHASH and locally finalizes it.

What does "locally finalizes" exactly mean?
I guess it's what we do in check_and_finalize_new_checkpoint in fork choice pseudocode, but without a check whether it's a new finalized epoch, so something like

def join_fork(block):
  set_head(new_block)

  casper = block.post_state.casper_contract

  db.last_finalized_epoch = casper.highest_finalized_epoch(NON_REVERT_MIN_DEPOSITS)
  db.last_finalized_block = casper.checkpoint_hashes(db.last_finalized_epoch)

Correct?

@gumb0

This comment has been minimized.

Copy link

commented May 11, 2018

Yes, do you think the spec should have a clarification on this?

I would add a clarification on what gas values should vote receipts contain, now with vote_gas_limit it's even more confusing

@nootropicat

This comment has been minimized.

Copy link

commented May 11, 2018

@jacob-eliosoff:

In particular, I don't understand your claim that starting with a reward >1.2 ETH is incompatible with 0.6 ETH being enough later.

The security of Casper FFG with 0.6 ETH in mining rewards is equivalent to the security of a pure PoW chain with 1.2 ETH in mining rewards, as exact same mining resources are enough to attack the chain. Therefore FFG+0.6ETH is equivalent to the assumption that 1.2 ETH in pure PoW is safe, therefore any higher reward is pure waste.

So whatever the phased rewards schedule is, the security argument for any reward above 1.2ETH is unequivocally incorrect.

Casper FFG is weird in that it's theoretically pure PoS, as cooperating stakers can force any chain they want, but in practice it reduces to pure PoW security (although more efficient than PoW without finalization) because no protocol for establishing such cooperation exists.

Insofar as the block reward quantifies PoW chain security, it would be more accurate to say it measures it in dollar terms than ETH terms.

Yes, that's what I wrote:

In addition, phased rewards make the chain less secure. Ceteris paribus, due to higher supply, the monetary value of mining rewards is going to be lower, which means lower hash power required for a successful attack.

The longer the reduction period is, the worse security of the post-reduction chain is going to be.

@jacob-eliosoff

This comment has been minimized.

Copy link

commented May 11, 2018

@nootropicat OK, I understand your point now about >1.2 being wasteful, thanks for clarifying. But what we're trying to do here isn't as simple as preserve some single measure of security. First of all, I disagree with your 0.6 FFG = 1.2 PoW equivalence: eg, I believe 51% PoW alone under hybrid-FFG is enough to a) control the PoW chain and b) censor votes, thus (eventually, after a long inactivity-leak delay) achieving finalization of the attacker's chain - no need for the separate tiny-bit-more-PoW chain. So, on the face of it, any reduction in block reward during the migration to FFG reduces protection against 51% attacks.

But even if I have some of that wrong - it's all secondary. The larger goals here are to 1. reach a state where the network benefits from the protections of both PoW and Casper (ie, finalization), while 2. minimizing risks, discontinuities, and pain of a reversion during the transition. #2 is the argument for gradually cutting the reward, rather than suddenly. (Personally, I agree that a month rather than a year should be enough for the transition, but I don't mind much either way.)

@djrtwo's analysis of the reward reduction is explicit that the goal is not to avoid reducing PoW security: we are knowingly reducing that security by 80%, back to where it was ~1 year ago, while adding the new protections Casper gives. (I'd like to see more people kicking the tires of that analysis btw, but perhaps in another thread.)

Another way to put this is (@djrtwo, correct me), if ETH's price hadn't risen in the last couple years, we probably wouldn't be doing this reward reduction until the pure-PoS stage. It's opportunistic, and IMO leaves the network plenty 51%-resistant enough.

(And btw new issuance during the next year is small relative to existing supply, so I don't buy the "longer reduction reduces security" argument. Among other factors, simple swings in ETH price will have a much larger impact on chain security.)

@jacob-eliosoff

This comment has been minimized.

Copy link

commented May 11, 2018

(I should add that the even larger goal here is to safely and securely migrate off of PoW entirely. But one step at a time)

@nootropicat

This comment has been minimized.

Copy link

commented May 11, 2018

@jacob-eliosoff:

I believe 51% PoW alone under hybrid-FFG is enough

In that case arguments about security fallback stop making any sense at all.

  1. minimizing risks, discontinuities, and pain of a reversion during the transition.

I agree with that and that's the problem - these terms are so general they aren't really an argument for anything. Keeping old rewards for long and slowly reducing seems like it minimizes risks- but alone that's the appeal to tradition fallacy! Risks and goals should be defined and decision made based on it.
It turns out that the current schedule asks miners to mine at a loss and therefore stalls, assuming rational miners.
The optimal solution is to drop the reward to 0.6ETH immediately and reduce difficulty by 80%.

Threat: intentional attack that profits externally from damage.
Define a function
costOfAttack(blockHeight) -> cost of attack in current dollars (ie. future cost is discounted with the risk-free rate)
that returns cost of an attack that starts at blockHeight, for arbitrary attacks.
Assumption 1 (A1):
Increasing ether supply has a net negative effect on price.
Assumption 2 (A2):
costOfAttack rises strictly monotonically with block rewards
Assumption 3 (A3):
PoW rewards value after finite phasing period: 0.6ETH
Goal 1 (G1):
maximize the minimum value of costOfAttack from HYBRID_CASPER_FORK_BLKNUM till infinity.

Given these three assumptions, the only answer that maximizes the minimum value for all attacks is an instant cut to 0.6ETH. Anything else decreases future security due to increased inflation.
For the fast (no waiting for decay) orphaning attack the answer is between 0.6 and 1.2. More precise answer requires knowing exact functions for results of inflation and costOfAttack, which is impossible.

Changing G1 means unequal weighting of security, ie. caring more about security at some moments.
Without A1 increased inflation could cause a higher price in the future, compared to the alternative without inflation.
Monotonicity ensures that costOfAttack doesn't drop with increasing rewards. Dollar discounting is theoretically required, otherwise you could safely invest dollars that aren't enough to attack today to attack in the future, which equivalently allows borrowing at a risk free rate to attack today.

Threat: incentives for profit-maximizing miners that harm the system
(miners profit from selling mined eth)
Assumption 4 (A4):
No selfish mining: no single entity (including cartels) controls more than 1/3 of the hash power and propagation is instant.
Assumption 5 (A5):
miners are rational and they don't mine at a loss.
Assumption 6 (A6):
(simplification) during short periods changes in ether's price are assumed to be negligible
Assumption 7 (A7):
(simplication 2) fees are ignored
Goal 2 (G2):
(no intentional orphaning) at all times the profit maximizing behavior for each miner is to mine on top of the chain with the highest cumulative difficulty.
Goal 3 (G3):
(no stalls) for a non-stalled system it's not possible to enter a state which requires breaking A5 to continue
Final goal:
G4 = G1 + G2 + G3

For a sharp drop from 3ETH to 0.6ETH, intentional orphaning of the last 3 ETH block (with a slightly higher difficulty due to a fake earlier timestamp) is the profit maximizing behavior. The minimum difficulty reduction allowed in one block is ~4.8%, but the block reward falls 80%. This enters into a feedback loop with increasingly higher difficulty for the last 3ETH block, until no earlier timestamp is possible.

The system stalls after that, as regardless of orphaning, miners would have to mine a minimum of 32 blocks at a loss. A rational miner is going to wait for someone else (free riding) instead, so nobody is mining any blocks.

The current proposed schedule suffers from stalling too!
The last drop by half requires 14 blocks mined at a loss.

The optimal fix: reduce difficulty by 80% for the first 0.6ETH block. This removes the incentive to orphan the last 3 ETH block.
Difficulty would start rising very fast (low block time) until least effective miners stop mining; eventually stabilizing like a damped oscillator.
Due to A5 the system never enters a state in which mining at loss is the only way forward; ie. pushing difficulty high enough requires breaking A5.

@atlanticcrypto

This comment has been minimized.

Copy link

commented May 12, 2018

@jacob-eliosoff

This comment has been minimized.

Copy link

commented May 12, 2018

I believe 51% PoW alone under hybrid-FFG is enough [to 51%-attack]

In that case arguments about security fallback stop making any sense at all.

@nootropicat What do you mean exactly? If all goes well, the hybrid rollout will maintain some (gradually shrinking) PoW protection, while adding Casper finalization: ie, reverting txs becomes much more expensive than under PoW. (Censoring is a separate story.) So along with being a stepping stone to pure PoS, hybrid Casper provides real security benefits.

If something goes wrong with the rollout, rolling back to pure PoW is definitely an option. This would be less likely to happen because "hybrid/Casper security is inferior", and more likely just due to a bug - ie, an engineering failure rather than a mechanism design one.

I think in general you're approaching this like a mathematical optimization problem (minimizing risk formulas etc), whereas I'm approaching it as an engineering problem, in particular change management. I strongly believe from my own dev experience that upgrades to production networks should include 1. minimal sudden changes to critical parameters and 2. a rollback plan. As @RadixPi and @Njcrypto noted above, a sudden 80% drop in block reward carries a much greater risk of disruption (slashed hashrate, hashrate redirected to attacks, erratic block times, price impact) than a gradual decline, particularly with the 80% drop coming at the exact same time as this major algo shift to hybrid PoS (and any hopefully minor bugs exposed in that, etc).

My ideal would be something like, block reward doesn't change for the first week (or two) after rollout; then it starts dropping, by a small amount each block, over the course of the next few weeks; with the drop stopping once it hits its target level of 0.6 ETH. But these are details: my main point is I agree with the others above that we should try to avoid a sudden drop like 3 -> 0.6.

@djrtwo

This comment has been minimized.

Copy link
Owner Author

commented May 12, 2018

@nootropicat

The security of Casper FFG with 0.6 ETH in mining rewards is equivalent to the security of a pure PoW chain with 1.2 ETH in mining rewards, as exact same mining resources are enough to attack the chain. Therefore FFG+0.6ETH is equivalent to the assumption that 1.2 ETH in pure PoW is safe, therefore any higher reward is pure waste.

This premise is false. First of all, seems to be assuming that miners and stakers are roughly equivalent in their contributions to security in the hybrid PoW/PoS model. This is not the case. Miners are severely limited in their ability to attack the network in this hybrid model. Even if a majority cartel censors FFG votes, a minority mining group can include votes in a side chain, finalize a new block, and void all of the work the censoring cartel had put into their chain. In fact, a minority mining group is incredibly incentivized to do.

The security of Casper FFG with 0.6 ETH in mining rewards is equivalent to the security of a pure PoW chain with 1.2 ETH in mining rewards, as exact same mining resources are enough to attack the chain.

It is also important to note that we actually get more security from staked ether per dollar than from traditional full PoW mining because if the stakers act nefariously, they will be punished via the slashing conditions making their attack a one-time attack. With PoW attacks an attacking miner who, once securing their hardware, can continue to conduct the same attack unless the PoW algorithm is changed.

Even if in the hybrid model we received equivalent security from stakers and miners we have no reason to believe that the dollar for dollar amount of staking vs mining will be equivalent. The security model, the amount of rewards paid, the reward distributions, the ease of securing the asset required, the life cycle of the asset, and the use of the asset outside of securing the network are all entirely different.

One day should be enough to get finalization started by prepared validators.

This has not backed by any empirical or theoretical evidence. We are currently unsure of how many validators will show up and how long it will take to get a significant number validating. Some more conservative validators will almost certainly wait for others to test the waters before they lock 1500+ ether into a contract.

There is also the scenario that enough security form validators does not show up at all given the economic parameters (interest rate/penalties) in the deployed contract. We do not expect this to be the case, but we will not know for sure until FFG is running for some amount of time.

EIP 960

EIP 960 is still in very early discussions and does not yet have clear community support. It is not on the roadmap and should not at this point be influencing the roadmap. EIP 960 also has another suggested total issuance if for some reason the 120M is passed before it can reach consensus and be implemented.

The only reasonable argument I can see is that more ether will be issued for longer and community members do not want this to be the case. I understand that this is a concern for some community members. I would venture to say that these same community members would want to see Ethereum recover gracefully in the event of any unforseen bugs, attacks, etc. If we reduce mining rewards quickly, we eliminate almost all recovery modes in the case of a failure in the new PoS system. We want to deploy PoS correctly, but more importantly, if there is something wrong, we want Ethereum to be able to recover and fix any issues rather than fail miserably.

Finally, it is important to consider what the options are for the immediately displaced 80% of miners. They can continue to mine at a loss, sell their hardware, or mine on different chains. Or they can do something more nefarious such as conduct an attack on the not-yet-stable new hybrid FFG chain, or maybe just keep mining on the old code and conduct a contentious fork. These are two scenarios that the community would rather avoid.

@atlanticcrypto

This comment has been minimized.

Copy link

commented May 12, 2018

@djrtwo

A caveat to this suggestion: you may have already outlined the reasons this will not work - but I don't have the time this morning to dig into it - so I'm just going to throw it out there....

If one of the worries is the adoption rate of early validators, why not scale into the eth deposit requirement to run a validating node? Just like with the block reward reduction, why not start the eth deposit min at 100eth and scale it up over time? This would allow for a much larger universe of early adopters. It also sounds like you already have the functionality written for trimming the validator set should someone's deposit fall below the minimum threshold? Unless the worry is that someone will deploy 1,000 validator nodes with 100eth each, and then control the finality consensus mechanism...

@djrtwo

This comment has been minimized.

Copy link
Owner Author

commented May 12, 2018

@Njcrypto
I expect at launch for there to be a number of staking pool implementations of varying rules, architectures, signature schemes, and ultimately levels of decentralization. These along with their varying tradeoffs should allow for enough accessibility for users of the 100 eth (and likely much lower) level to participate.

Because of the option of pooling, it is not the minimum staking requirement that I am concerned with. It is the risk/reward assessed by potential stakers due to the reward and penalty scheme along with the capital lockup time (logout and withdrawal period). If these values are too far off, I could see not enough capital coming to secure the network in the long run.

In the short run, even if enough capital is going to come eventually, I expect a significant amount of capital to sit at the side lines at least for some period of time to observe the mechanisms in action before making the plunge.

A note about "trimming" the validator set. The current contract does not provide any mechanisms for kicking out validators that fall below the minimum deposit threshold. It is a minimum deposit, not a minimum participation amount. If inactive, a validator can bleed to a tiny amount of eth and then come back online to continue validating.

We have experimented with a dynamic minimum deposit that scales up as the number of validators enters but this actually brings in a number of technical and game theoretic challenges that we have decided were a premature optimization before launching this initial contract. The funding crunch will provide a good point in time for a significant analysis of real validation to inform an updated contract if necessary.

@atlanticcrypto

This comment has been minimized.

Copy link

commented May 12, 2018

@djrtwo

Understood re: pools. Unfortunately, the level of transparency in a lot of existing mining pools isn't great; hopefully there are adults in the room for staking pools and these entities are of "Big 5" audit quality.

In my opinion, the risk/reward of operating a validator node isn't attractive. I am unwilling to lockup an ETH deposit for ANY amount of time for 10.12% per year, nevermind 2.48% per year with a 4 month logout delay on the other extreme.

It's not a perfect example, but consider selling a 12 month maturity American 10 delta call option as an alternative to running a validator node. When pricing it, let's use the average close-close 90d realized volatility from 9/1/2016 through 5/11/2018, and let's use standard black scholes [haven't put thought into the correct model, this will get us most of the way there]. Prices are close price generated by the CryptoCompare API from Bitfinex.

Annualized Volatility (90d) = 119.40%
Days to expiry = 365
Underlying price = $675
Risk-free rate (12m USD LIBOR) = 2.76579%

The 10d call strike price, using those inputs, is USD 6,250 / ETH.

The theoretical price of that option is USD 27.16. That's 4.02% of current ETH price to have my ETH called away at USD 6,250. And that assumes no vol-skew! I would do that trade every single time before I would lock ETH in a validator contract with a 4 month delay. At least under this structure I have the ability to manage my financial exposure.

I'm not sure who would prefer locking their ETH in one of these validator nodes? With alternative sources of income generation (albeit, it is not a pure substitute), it doesn't seem like a rational financial decision to me.

Securing these networks is not and should not be cheap. This is the wild-west, and I believe risk premiums required to participate are way higher than the proposed interest for ETH validators.

@nootropicat

This comment has been minimized.

Copy link

commented May 14, 2018

@Njcrypto:

Realistic point 3: the market will solve for what the appropriate USD equivalent reward should be to operate the consensus infrastructure

The market doesn't solve for that. For a market to work a security arbitrage would have to be possible, meaning it's possible to 'sell' excess security and buy 'too low' security. The only way to 'buy' too low security is to attack the network. There's no way to 'sell' excess security.

@djrtwo:

First of all, seems to be assuming that miners and stakers are roughly equivalent in their contributions to security

Not equivalent. FFG is either equivalent to pure PoW with doubled security or pure PoS assuming extra-protocol cooperation.

Even if a majority cartel censors FFG votes, a minority mining group can include votes in a side chain, finalize a new block, and void all of the work the censoring cartel had put into their chain.

That's pure PoS, because this requires out of band cooperation of validators to arbitrarily choose a chain. You're describing an attack that cuts miners out. The validators would only need some initial mining to drop the difficulty enough to mine on their own PCs and that would be it, they would have all mining rewards for themselves.
If not for fact the that this attack would create an uproar and result in an anti-PoS hard fork it would be a real risk.

This has not backed by any empirical or theoretical evidence.

Neither is phasing rewards over a year. There doesn't seem to be any model or analysis that leads to the proposed schedule. Why 12 months, and not 3, or 4.5? If lack of sufficient finalization is the threat and censorship by miners is not a factor, mining rewards should drop soon after validators' deposit achieve some threshold.

I can see is that more ether will be issued for longer

While not crypto related, some people see PoW as evil due to the enormous amount of pointless pollution it causes. Globally the cheapest energy is the dirtiest one. Compared to the fast reduction alternative, the proposed schedule adds a year's worth of pollution from a middle-sized country running exclusively on brown coal.

@atlanticcrypto

This comment has been minimized.

Copy link

commented May 14, 2018

@jacob-eliosoff

This comment has been minimized.

Copy link

commented May 14, 2018

Even if a majority cartel censors FFG votes, a minority mining group can include votes in a side chain, finalize a new block, and void all of the work the censoring cartel had put into their chain.

That's pure PoS, because this requires out of band cooperation of validators to arbitrarily choose a chain. You're describing an attack that cuts miners out. The validators would only need some initial mining to drop the difficulty enough to mine on their own PCs and that would be it, they would have all mining rewards for themselves.
If not for fact the that this attack would create an uproar and result in an anti-PoS hard fork it would be a real risk.

This isn't an "attack" by validators. They'll be able to detect when their votes aren't making it to the main chain. It's entirely correct for a validator to refuse to vote for a checkpoint whose chain omits the validator's own vote (perhaps this should be in the default validator logic). Yes, this would lead to a messy situation, but I agree with @djrtwo that the honest mining minority would be strongly incentivized to work with validators to produce and finalize an uncensored chain. I suppose they'd have to coordinate a soft fork, eg rejecting any block that was part of a chain that didn't include recent votes from enough of the validators.

The point isn't really that this on-chain fight would be won by the good guys. It's that it would be quickly detected (votes omitted), raise an alarm in the community, and almost certainly lead to an off-chain resolution that left the censored chain near-worthless. This is the strong incentive against the censorship attack. (And note that under pure PoW, recovering from attack by a 51% cartel is much harder.)

@nootropicat

This comment has been minimized.

Copy link

commented May 14, 2018

@Njcrypto:

The arbitrage exists in the substitute uses of mining hardware.

That's the arbitrage between general profit from mining (which includes attacks!) and other use of hardware and energy, not arbitrage for the minimum secure mining rewards.

Your point about energy consumption and pollution is uninformed

https://spectrum.ieee.org/computing/networks/why-the-biggest-bitcoin-mines-are-in-china
https://qz.com/1250980/an-australian-coal-power-plant-will-reopen-to-help-mine-bitcoins/
https://voiceofpeopletoday.com/russia-first-time-power-plant-bought-mining-crypto-currency/ (GRES = coal)
"In Inner Mongolia, for instance, Bitmain is partnering with the local government to access electricity from the State Grid for about four cents per kilowatt hour"
https://medium.com/@evawxiao/cheap-electricity-made-china-the-king-of-bitcoin-mining-the-governments-stepping-in-118c20725f7b
If coal energy wasn't profitable for mining, miners using it would get outcompeted a long time ago.

@jacob-eliosoff

This isn't an "attack" by validators.

FFG security model assumes that miners are separate. When they aren't, you get potential problems: stake grinding, censoring joins of new validators, or potential thefts due to randomness (block hash) control (probably not an actual risk). It's not a very secure design. When then happens the only way to defend is to:
"You just ask client developers to run their clients with a “–follow-pow-chain” setting, which would instruct them to ignore PoS votes." to quote Vitalik.
which is a hard-fork, as validators taking control means everyone is on their chain, so the only practical option is to fork from it. As it's a hard fork, PoW rewards could be increased as well.

raise an alarm in the community, and almost certainly lead to an off-chain resolution that left the censored chain near-worthless

That's not possible to achieve in the span of 500 blocks (~2 hours). First censor to prevent finalization for 500 blocks, then orphan them all. That would be enough to destroy the network, at least in the short and medium term, and that's why FFG only doubles PoW security.

@jacob-eliosoff

This comment has been minimized.

Copy link

commented May 14, 2018

@nootropicat, please stick to one topic at a time, it's hard to have a productive exchange when you bounce around like this. I replied to your scenario where the miners censor the votes. Now you're talking about validators seizing control. What specific attack are you talking about, and which group is behaving dishonestly in it?

That's not possible to achieve in the span of 500 blocks (~2 hours). First censor to prevent finalization for 500 blocks, then orphan them all. That would be enough to destroy the network, at least in the short and medium term, and that's why FFG only doubles PoW security.

  1. This is very hard to understand ("orphan them all" - who?)
  2. You haven't proved that FFG only doubles PoW security. In particular, you haven't addressed the point that FFG makes it much harder (much more than 2x) to revert finalized txs.
  3. Even if FFG did "only double PoW security" - who cares? The primary goal here is safe transition to pure PoS. Any attack that presupposes 51% hashrate is already a vulnerability anyway.
  4. What does the attacker gain here? Whether it takes two hours or two weeks, the outcome will be the community forking to a fresh chain not controlled by the attacker, and the attacker's chain plunging in value.

I'm just going to ignore your posts until you make them clearer. So far you haven't described a single feasible attack against the hybrid Casper FFG proposal we're supposed to be reviewing here.

@bmcbee85

This comment has been minimized.

Copy link

commented May 14, 2018

@nootropicat

While not crypto related, some people see PoW as evil due to the enormous amount of pointless pollution it causes. Globally the cheapest energy is the dirtiest one. Compared to the fast reduction alternative, the proposed schedule adds a year's worth of pollution from a middle-sized country running exclusively on brown coal.

I like math. I also like data. Real data, which are produced by real government entities. Especially when it is empirical data.

The reason I like math and data is that it cannot be argued with. It is just facts. And facts are informative to real life issues.

I also like data because it can be put in context. For example, what exactly is 1 million tons of carbon emissions? Sure, it sounds big, because it completely lacks context. But, 1 million tons of carbon is actually 0.00263% of global annual carbon emissions: Source EIA

What you have posted are not facts. You posted opinions. Opinions put forth by websites whose sole-purpose is to generate income through ads and selling your data. You also did no research on your own. You just re-posted opinions. Which is simply lazy, misleading, and does not contribute anything to the conversation.

Here are the facts about energy consumption and carbon emissions from Ethereum. This is research I have done. I am familiar with this data because I have been an energy analyst for over a decade and I have been published in scientific journals for my research.

All data sourced from the Energy Information Administration (eia.gov) and the 2017 International Energy Outlook (https://www.eia.gov/outlooks/ieo/). For clarity, this is the United States Energy Administration's opinion on global electricity generation and production. This also covers global carbon production. There is no better source of unbiased global energy and emissions data.

Questions answered in this analysis:

What is the energy consumption (today) of securing the Ethereum network?
What is the carbon emissions associated with this?
And how are both of these values relative to 1) global electricity consumption and 2) global carbon emission.

Analytical Process, with real data sources.

  1. What is the Global Generation Mix?
  • This allows for identification of what generation sources are used for the average unit of electricity production. It is irresponsible to assume 1 source of energy generation for analysis (i.e. coal). I use the global mix as the country placement of generation sources is not known. Are there big miners in China? absolutely. But there are also big miners in Canada, Russia, Kazakhstan, Vietnam, USA, etc. Point being, the responsible analytical approach is to use the average global generation mix. Source of data: EIA

Answer (2017 Data):

Coal: 40%
Liquids: 3%
Natural Gas: 20%
Nuclear: 12%
Renewables*: 25%

*Defined as: Solar, Wind, Run of River Hydro, Dam Hydro

  1. What is the carbon emission rate of each generation source within the generation mix?
  • This data has many sources. Because I like empirical data, I am going to use data summarized from the Continuous Emission Monitoring System (CEMS) hourly dataset of energy generation. Note that all data reflects the average heat rate (mmbtu/MWh) for fuel sources. This includes combined cycle and combustion turbine units. This is the appropriate metric to use. This data is summarized by the EIA.

Coal: 1.125 tons/MWh
Liquids: 1.217 tons/MWh
Natural Gas: 0.496 tons/MWh
Nuclear: 0 tons/MWh
Renewables: 0 tons/MWh

  1. What is the average, global emission rate per MWh of energy produced?
  • Pretty straightforward, but math is below.

Generation Stack Carbon emissions from Coal: 40% * 1.125 = 0.45 tons/MWh
Generation Stack Carbon emissions from Liquids: 3% * 1.217 = 0.03651 tons/MWh
Generation Stack Carbon emissions from Natural Gas: 20% * 0.496 = 0.0992 tons/MWh
Generation Stack Carbon emissions from Nuclear: 12% * 0 = 0
Generation Stack Carbon emissions from Renewables: 25% * 0 = 0

Generation Stack Fuel-Weighted Emission Rate: 0.58571 tons/MWh

Answer:

The global carbon emission rate from 1 MWh of electricity production is 0.58571 tons/MWh.

  1. What is the current electricity requirement of securing the Ethereum network?
  • For this calculation, we must identify the average wattage per MH for mining Ethereum. Then, we multiply this wattage value by the total amount of MH on the Ethereum network.

For the average wattage per MH, I am going to use the Manli Mining System. I am using this because this group has optimized this unit to be efficient (overclock, undervolt).
Hashrate: 225 MH/S
Wattage: 1,100w

Watts per MH: 4.9w/MH

Now that we have the wattage of the network, we just need to multiply this by the total network hashrate. Source :

Ethereum network Hashrate in MH: 278,287,000 MH/s

Total Ethereum wattage: 278,287,000 * 4.9w/MH = 1,363,606,300 Watts. Or, 1,363.6063 MW.

Answer:

The electrical requirement of securing the Ethereum network is 1,363.6063 MW.

  1. What is the Carbon Emissions associated with the Ethereum network?
  • Using the analysis from above, I am able to estimate the daily Carbon emission rate, and then the annual carbon emission rate.

Amount of MWh consumed by securing Ethereum per day: 1,363.6063 * 24 hours = 32,726.5512 MWh.
Total daily carbon emissions from the Ethereum network per day: 32,726.551 MWh * 0.58571 tons/MWh = 19,168.268 tons of carbon per day.

Answer:

The daily carbon emission rate from securing the Ethereum network is 19,168.3 tons per day.
The annual carbon emission rate from securing the Ethereum network is 6,996,429.5 tons per year.

  1. Now, the most important part of the analysis. These numbers must be put in context.
  • This is the part of the analysis the community is missing. What do these numbers actually mean? How are they relative to other industries? I again will use the EIA as data sources for Carbon and for Electricity Consumption .

6a. What percentage is the Ethereum network of global electricity generation?

Daily global consumption is 132,526,575.34 MWh.
Daily Ethereum consumption is 32,726.5512 MWh.

32,726/132,526,575 = 0.025%

Answer: Securing the Ethereum network currently accounts for 0.02469% of global electricity consumption.

6b. What percentage is the Ethereum network of global carbon emissions?

Daily global carbon emissions in 2017 is 104,219,914 tons
Daily Ethereum carbon emissions is 19,168 tons

19,168 / 104,219,914 = 0.01839%

Answer. Securing the Ethereum network currently accounts for 0.01839% of global carbon emissions.

This is the data. I find it very difficult to argue with my approach, and I find the data sources to be completely sound. Feel free to draw whatever conclusions from it that you'd like.

@jacob-eliosoff

This comment has been minimized.

Copy link

commented May 14, 2018

@nootropicat "Seizing control": My point was that you're conflating "validators defending against miner censorship" with "validators launching a takeover attempt". As long as everyone stays honest (miners including votes, validators following PoW), your conflict never happens. Someone has to launch an attack, and whether it's the miners or the validators are two totally different scenarios.

500 blocks: ah, OK, understood.

Inflation: ETH issuance is ~6.3m/year, so the difference between cutting it 80% over a year vs instantly is 40% of ~6.3m ≈ 2.5m, ie, ~2.5% of the 100m total supply. It's just not a major factor relative to the others involved here (eg, price impact of a crisis/rollback during Casper rollout).

@nootropicat

This comment has been minimized.

Copy link

commented May 14, 2018

@jacob-eliosoff:

Now you're talking about validators seizing control.

Ok, you're right, it was confusing. I deleted the old comment.

Validators seizing control as the expected solution to misbehaving miners is equivalent to claiming that security of PoW is irrelevant. If it's irrelevant then PoW could and should be cut out completely once finalization starts working.
The problem is that miners aren't irrelevant because FFG requires working PoW for security assumptions.
Which means that validators seizing control is not an acceptable solution to an attack by miners.
The gain from a working finalization is that the most damaging attack requires 2x mining resources compared to a PoW chain without finalization.
Therefore, FFG's security is equivalent to security of a PoW chain with 2x rewards, and its security should be analyzed as such.

("orphan them all" - who?)

500 blocks.

that FFG makes it much harder (much more than 2x) to revert finalized txs.

The attacker has first to mine a 500-block most valid chain while censoring finalizing votes, then orphan his own 500 blocks with another more valid chain. That's why PoW security doubles.
Without finalization it would be possible to replace 500 most valid blocks at once.

who cares?

Higher inflation means that future rewards are worth less, so they should be minimized even if only for security. Rewards are economically in fractions of the total supply, ether is only a unit equivalent to a constantly dropping fraction.

What does the attacker gain here? Whether it takes two hours or two weeks, the outcome will be the community forking to a fresh chain not controlled by the attacker, and the attacker's chain plunging in value.

The point is to profit from the damage itself. It absolutely wouldn't be a minor event. Even if every exchange and other businesses stopped using ethereum immediately, the fact than an attack of this magnitude succeeded would be damaging enough to potentially destroy the network.
Right now it's a theoretical use case, but things cross-chain swaps would make reversing damage impossible.

@jacob-eliosoff

This comment has been minimized.

Copy link

commented May 14, 2018

Guys, how much energy PoW uses + what kinds + its impact on the environment is a huge topic better discussed elsewhere. Let's stick to the EIP.

@nootropicat

This comment has been minimized.

Copy link

commented May 14, 2018

@jacob-eliosoff:

Inflation: ETH issuance is ~6.3m/year, so the difference between cutting it 80% over a year vs instantly is 40% of ~6.3m ≈ 2.5m, ie, ~2.5% of the 100m total supply. It's just not a major factor relative to the others involved here (eg, price impact of a crisis/rollback during Casper rollout).

The impact lasts forever and that 'small' percentage is ~$2.6B at current prices. As market caps are high multipliers of actual demand it could realistically translate into losing $5B-$10B of PoS security, forever, as most of that money is going to miners to burn. As I don't see any reasoning that could support >1.2ETH, and 1.2ETH only before FFG starts working, throwing ~$2.6B away seems wrong on multiple levels to me. Objectively that's an enormous amount of wealth. Personally I would even prefer to issue new ethers to replace those lost in the Parity's multisig bug rather than see the equivalent amount sold to pay for mining.

It's a bit more than 2.5M, 5.5e5*(0.6*5+0.6*4+0.6*3+0.6*2) - 5.5e5*0.6*4 = 3.3M
(proposed - cut at once)
something from uncles gives uh... 3.5M? At $740/ETH = $2.59B

I guess that's all from me.

@jacob-eliosoff

This comment has been minimized.

Copy link

commented May 14, 2018

You're still not addressing the risks from a sudden cut to the reward. Of course if there was no risk difference, why issue more? You might as well argue Casper should be rolled out next week (or the reward made 0.5 rather than 0.6) because every month's delay costs >$250m in extra supply. This is a huge change we're only getting one shot at - prioritizing stability over saving a few % is just sound engineering. Anyway I've had my 2c.

OK, your 3.3m(+) ETH number is correct.

@bmcbee85

This comment has been minimized.

Copy link

commented May 15, 2018

@jacob-eliosoff While I agree there is a better forum for discussion of Electrical consumption and Carbon emissions, I do argue that it is an important consideration for this debate. My understanding is that the carbon emission and electrical consumption to secure Ethereum through PoW is one of a few driving factors for a push to PoS.

However, no one has truly put forward the factual numbers in context. The analysis I present above is the first attempt at that. Admittedly, it can be expanded. And I am happy to do so.

So, what is the most beneficial forum? I would think that a full analysis/discussion on what these real impacts are should be completed before using it as one of the main arguments for a push to PoS.

@jacob-eliosoff

This comment has been minimized.

Copy link

commented May 15, 2018

@bmcbee85 Fair question! I don't really know. There's always Reddit and my fave, Twitter. Or there may be a better Ethereum forum, but anyway it's too big & broad a topic for this EIP review.

@djrtwo

This comment has been minimized.

Copy link
Owner Author

commented May 16, 2018

Just released an update to the EIP.
See changelog above in top issue comment

@bmcbee85

This comment has been minimized.

Copy link

commented May 16, 2018

The economics need to be more critically assessed. There is a very worthwhile discussion on Reddit currently ( https://www.reddit.com/r/ethereum/comments/8jg38e/the_economics_of_ethereums_ffg/ ) which very reasonably questions the underlying assumptions.

@djrtwo djrtwo referenced this issue May 16, 2018
0 of 19 tasks complete
@jacob-eliosoff

This comment has been minimized.

Copy link

commented May 16, 2018

@djrtwo I see the definitions of epoch etc were cleaned up - good. But you should add "explicitly" here, because "number of finalized checkpoints" is too ambiguous in a doc that elsewhere refers to both explicit and implicit finalization.

  • dynasty: The number of explicitly finalized checkpoints in the chain from root to the parent of a block.
@sorpaas sorpaas referenced this issue May 18, 2018
1 of 3 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
10 participants
You can’t perform that action at this time.