Hence the point of this thread 
1 Like
Another more recently introduced mechanic is that the withdrawal rate is fixed, meaning that the expected (and max) time for a validator to withdraw is proportional to the amount of ETH staking. This reduces the lockup periods in staking if few other validators are staking, further stabilizing the total validator set size.
1 Like
I’ve done it too, and it’s extremely easy, I know. “I know” doesn’t mean much.
Guess what, I’ve done this too, and it’s way harder that plugin ASIC(s) to work. I know. And of course there is key management, what are you trying to say?
I’m not missing the point and I won’t be surprised, but that was already explained to you in the comments above.
I would highly advise discussing things in a more respectful and objective way. The best would be to get yourself familiar with the rules of the forum.
3 Likes
I disagree. Experience actually running large scale mining operations, means a lot. Until you do it, you do not know the real world challenges you face. If it was easy, we wouldn’t be seeing ETH hashrates drop to January levels so quickly. You can say it is because of power vs. coin pricing, but look at GigaWatt… they have stupid cheap power and still went bankrupt. There is a lot more to ASIC mining with hardware than there is to PoS mining running on VPS servers.
This is totally subjective. Maybe DevOps is hard for you and is easy for me. Maybe the hardware you used was solid and mine was junk with massive failure rates (true story). Relying on something subjective as a mechanism for security feels like a fast path to failure.
What I am trying to say is that the key management is offloaded from the actual instances. I can generate a wallet.dat file and copy it onto the server using automated mechanisms. The key management portion does not affect the validator nodes themselves. It isn’t an obstacle like you’re making it sound.
I agree. I apologize and my mistake.
Again, agreed. I apologize. Thanks for your patience.
2 Likes
Accepted, all good. 
We need to keep this place cozy as it is now, we don’t want it to turn into crypto twitter. 
1 Like
What a great thread. Seriously, I’m glad to see you two talking actually! I’ve mined since 2012 and @lookfirst ran THE sickest operation I’ve ever heard of. I literally nagged him to join this topic and throw his two cents in to provide his PoV as a legit professional miner. That’s one thing that I’ve found in this community is a lack of legitimate experience mining and somewhat of a disconnect when trying to understand a miner’s PoV.
2 Likes
IMO the level of incentive will be just as important as the ease of staking and what that product looks like. Happy to discuss some of the things we are working on at Token Foundry.
1 Like
How did you arrive at the ~$6,000 POS Validator cost?
As Ethereum Put Contracts evolve it will allow for a portion of validators (professional validators) to hedge downside risk on bonded Ether. As a validator I would personally have my risk hedged before an event hits that would push me to liquidate early. However the sophistication of certain validators cannot be accurately predicted. Also who knows when Ether derivatives will be widely available.
On your point about which variable to fix - please see below (ran out of reply’s)
IMO interest should be ‘priced’ dynamically based on a set of desired outcomes (based on security, total node count, target TPS - whatever the community deems to be the core focus of the protocol). @vbuterin I agree that the first option above at the beginning is worrisome - maybe once everything reaches scale (TBD measurement) at that point I would hope that a dynamic/systematic approach to interest is taken - behavior is quite understandable and that won’t ever change.
Oh great, didn’t know that. Thanks for participating @lookfirst, please feel free to share your thoughts in future!
It was just the fiat price of 32ETH on that date, I didn’t factor in any of the setup&running costs.
Implications of a well-functioning derivatives market on network incentives is a topic to discuss separately. Feel free to start a new thread. I posted a general answer about the implications in the ethHub response to the CFTC RFI (link) in answers 18-19, but it’s clear that more perspectives are needed. Most would agree that it would be a good thing assuming they’re well-regulated, but the limits of the market would depend on the network design under discussion here.
He’s referring to the calculation of the base_reward via the total amount ETH deposited by validators. It multiplies a given validator balance by the inverse square root of the total balance * the BASE_REWARD_QUOTIENT
Thanks for the explanation @vbuterin. The PDF was helpful for visualization purposes. Going back to @econoar 's original point though, even if we’re using an inverse root function instead of a constant, overall issuance rate, we’re still imputing the constants into the calculation which pegs a expected rate of return to a given total of staked Ether. Any deeper thinking behind how numbers such as the BASE_REWARD_QUOTIENT were created? There’s no documentation that I could find.
Could you please expand on this a bit, couldn’t understand it?
Curious about this, too.
Just read this again (refers to the “total issuance” model for rewards). Why would the deposit size be variable, isn’t it better to only have one variable (inflation)? With two variables it should be exponentially harder to reach some sort of equilibrium?
I have been thinking about this, and:
a) I can’t come up with any realistic scenario how this selfish mining/griefing (I guess we could say selfish mining is a special case of griefing attacks?) could be realized?
b) Even if it can be realized, I guess it would be a realistic threat only if the attackers can afford to perform it more or less permanently, otherwise new validators will enter the system relatively fast and replace the old ones (the ones who left)? Of course, here I’m assuming that the cryptoeconomic model is designed to increase the rewards if the number of validators drops, as discussed above.
Sure! The spec says that you take the square root of the total amount staked, multiply it by the BASE_REWARD_QUOTIENT, divide by four, and then divide the effective balance by that amount to come up with the base reward (snipped a pic in my answer). In essence the relationship between the total balance of staked ETH and the reward is described by an inverse square root function.
Per Vitalik’s PDF, this was done to reduce the potential reward (vs. rewarding a flat inflation amount no matter what) for performing an “epsilon attack” whereby you grief a subset of validators and take a larger share of the staking reward pot for yourself. Basically, the design goal is to make it less profitable to forcefully reduce the overall number of validators to concentrate rewards. The PDF was helpful in explaining this.
I was saying that this idea makes sense, but we’re still using certain constants (e.g. fixed numbers) like the BASE_REWARD_QUOTIENT which helps determine a baseline for how much Ether is rewarded. For example, adjusting the BASE_REWARD_QUOTIENT up would make all rewards smaller, while adjusting it down would make all rewards larger. Hence our questions for where it comes from.
For the record, it’s not like I have a “right number” in mind. I’m just curious how we think about these things.
Thanks @haokaiwu.
Can you share the link to the PDF (if it’s public)? Does it maybe contain any practical explanation/example of a real-life epsilon/griefing attack? I’m asking because I couldn’t come up with one (but I’m not yet saying it’s unrealistic to expect it in reality).
@MihailoBjelic , it’s the PDF posted by @lookfirst on comment 35.
The PDF describes an attack that occurs completely on-chain (don’t think the PDF goes into the exact mechanism), but it’s a plausible way to attack the network offchain as well simply by taking large swaths of the network offline. This whole argument is just a technical way of saying that, if it’s too profitable to take stakers offline and hoard the rewards, someone’s sure to try it.
One scenario: I’m imagining someone targeting somewhere like RocketPool or Coinbase to take their validator clients offline. If they can do this for extensive periods of time, they can reap significant rewards by becoming a larger percentage of the stake. As for attacking via on-chain censorship, I can’t speak to an example either.
Thanks @haokaiwu, I’ve just read the paper, it’s insightful.
Yes, I thought of this same thing while I was reading the paper, offline attacks are a way more realistic threat IMHO. Even existing miners/pools are more or less constantantly under DoS and other attacks (especially when important/controversial protocol-related decisions are being or about to be made), so I guess there’s no reason for this not to happen with (large) validators. For this and other (obvious) reasons, I think the client/validator software should be designed to make running large number of validator clients a challenging task (the complexity/resources/work required should, if possible, increase linearly with number of validator instances, not logarithmically).
How would you go about making that happen exactly? Add a captcha on every install so things cannot be automated? 
1 Like
Haha I’ll be thinking about this in my free time and I actually really hoped you will read my comment and drop some smart suggestions.
1 Like
