protolambda on dev
Remerkleable - merkle tree base… Merge pull request #1552 from e… (compare)
<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
<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
<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
<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.
eth2 call in 11.5 hours
youtube chatbox: https://www.youtube.com/live_chat?v=kt59-FEeWTI&is_popout=1
<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: