https://cdn.discordapp.com/attachments/598292067260825641/669297173514682389/3.png
<djrtwo> That is correct.
Essentially, at least a slap on the wrist, and then scaling with 3x the % of the network that has recently committed a fault such that if 1/3 do something slashable recently (enough to commit a network fault), slashed validators are maximally punished
<djrtwo> I see the appeal here, but am concerned about making validator failures seem inconsequential such that validators won't take the proper guards and leave themselves more at risk. Also concerned about reasonably punishing validators if committees are corrupted. This is more of a concern come Phase 1 (and thus @vbuterin's recent PR), but still not settled.
I'm chewing on it some more and soliciting more feedback
This is the primary audit/verification. The contract and FV work is now for public review. I'll be explicitly requesting review from some teams/individuals and will make a call out for it in my next blog post
Please add items to the agenda. We'll focus on the practical issues we face today in testnets and if time beyond that discuss more far out items
ethereum/eth2.0-pm#124
<jgm> > I see the appeal here, but am concerned about making validator failures seem inconsequential...
I wouldn't want slashing penalties to be inconsequential, but given that they already lose 1 Ether and are forcibly ejected from the validating pool (with a very long exit time) that seems like quite a chunk of punishment as-is for situations that aren't network-threatening. And if something similar comes in for committees I think this would become more important, given the much smaller size of a committee Vs. the entire validator pool.
My mind wanders to future failures of software, or hacks of large staking services, that results in 15% of total validators slashed. If they lose 50% of their balance it's going to be a much harder for the next person to decide to deposit, whereas if they lose 10% of balance value I think it would be less of a drag on adoption. Given that such an attack wouldn't be network-threatening (in phase 0, anyway) it can be hard to sell the harshness of the punishment.
<djrtwo> This is only a security concern when using a custodial service for a full deposit (units of 32 ETH for a single user) in which the user retains control of the withdrawal credentials. The solution in the PR led to weird front-running exploits and didn't really provide an adequate solution.
The communications protocol I outlined here is a valid and safe way to achieve the goals of the user/custodian without modifying the deposit contract and without exposing the signing key on the wire
https://github.com/ethereum/eth2.0-specs/pull/1506#issuecomment-564086671
<jgm> > The solution in the PR led to weird front-running exploits and didn't really provide an adequate solution.
That was stated but never explained.
<djrtwo> I broadcast a deposit, attacker broadcasts another deposit with my data (with min 1 eth) and changes the withdrawal credentials to their own, my tx now fails.
Likely this annoyance is not worth 1ETH to an attacker, but confusion at early stages of depositing might be sufficiently discouraging for participation in general. Note that this attack is available on all deposits, not just custodial services
Phishing attacks of any sort are a major issue and the best we can do in most cases is education. I know that the day we launch teh deposit contract, there will be 10 fake addresses circulating around. An unvetted service can trick a user in any number of ways
<jgm> So you don't agree with this statement then?
If the deposit contract is given a deposit with specific withdrawal credentials it should result in either the deposited amount being withdrawable by those credentials or the deposit being rejected.
<djrtwo> I do not think that that must be a strict requirement for the system to be secure.
The basic deposit contract ensures that a user staking for themselves will be able to safely make their deposit and specify their params. The protocol outlined in the link I shared allows for more flexibility in doing the same in custodial solutions.
Both scenarios allow for a secure setting of all params of the validator. Once these are set (including withdrawal credentials), the user is safe from any subsequent attempt to modify them as a deposit with wrong credentials would simply increase the validators balance.
<jgm> > I do not think that that must be a strict requirement for the system to be secure.
I think you would struggle to convince someone who loses their stake after signing a deposit with their withdrawal credentials in it that the system is secure, I really do. Let's hope it doesn't come to pass.
<djrtwo> --------------------------
eth2 call in 11.5 hours
agenda: ethereum/eth2.0-pm#123
stream: https://www.youtube.com/watch?v=kt59-FEeWTI
youtube chatbox: https://www.youtube.com/live_chat?v=kt59-FEeWTI&is_popout=1
Hi all, I'm wondering whether there's more definition available for the 'bonding' mechanism to share ENRs which are then added to the Discovery node table in order to be trusted for FINDNODES queries. afaict clients are statically bootstrapping ENRs into their node table.
<Jannik> > shahankhatch
Hi all, I'm wondering whether there's more definition available for the 'bonding' mechanism to share ENRs which are then added to the Discovery node table in order to be trusted for FINDNODES queries. afaict clients are statically bootstrapping ENRs into their node table.
@telegram bridge The bonding mechanism is described in these two documents:
A FINDNODE query can only be issued after a session is established. If I'm a single peer with another node's ENR, and that node doesn't have my ENR in their node table, they won't respond. Similarly, after issuing a FINDNODE query which returns ENRs, the ENR is known only to one party, however the specification requires that the target peer have the ENR of the source node. So there's a data race condition without a separate ENR sharing mechanism, which is what Kademlia has been proposed for.
Thanks for pointing me to Trinity's approach. A closer look there shows the following constraint check on presence of a peer in the node table, if I am reading that correctly? https://github.com/ethereum/trinity/blob/7224a5a8da41e77d36c03f7e5f5e6a7b6771fa5f/p2p/discovery.py#L692