Check if deposit for the same validator pubkey was already made

[Phistr90]

Hi, I just customized my local launchpad to work with Altona. Works fine so far but what I noticed is that you can deposit multiple times for the same validator. Would be nice if we could check if a deposit to the same validator pubkey was already made and if oldDeposit + newDeposit > 32Ether and disallow to continue in that case.

[CarlBeek]

Agreed that that would be very cool to check for existing deposits to a given address, but it is not possible without either following the eth2 chain (infrastructure to do so doesn't currently exist), or having RPC access to the full transaction history of the eth1 chain, as this information is not stored in the deposit contract.

[Phistr90]

Cant you check it with the event logs? We do need to have a web3 provider anyway, right?

[dankrad]

There may be reasons when you want to top up your validator so that the total amount sent is >32 ETH:

1. Your validator balance might be getting dangerously close to 16 ETH due to inactivity leaks/slashing
2. You may want your effective balance to stay at 32 ETH after a small amount of loss has brought it down to 31
3. Once transfers are enabled: Just to use the balance, independent from validator duties.

Since the deposit contract won't be changed, it does seem like a bad idea to implement a limit at deposit contract level.

[CarlBeek]

I was under the impression that web3 did not support historical logs (beyond when you started watching), but I was mistaken. That said, there is a chance we run into the limits of a given web3 provider if the user is using one which has limits on the how many events can be returned (eg. Infura only returns 10000 events). That said, it is not my area of expertise, @Battenfield, can you weigh in on the feasibility of using myContract.events.allEvents([options][, callback]) with a filter on the pubkey?

@dankrad, while I agree a user should not be stoped from making a deposit for an existing validator, they should be warned and ideally taken through the separate top-up deposit flow (which is a planned feature).

[Phistr90]

@dankrad I agree that we should generally allow for topping up. That said with adjusted hysteresis earlier this year, there shouldn't be much incentive to initially deposit more than 32ETH. I also think we should have another flow for that and at least warn the user. Otherwise I foresee a bunch of users depositing twice accidentally or thinking that they can deposit for 2 validators and having their funds stuck there until transfers are possible.

Ideas for workarounds (not great but better than nothing) if the event log history is too limited:

• Use cookies / local deposit log
• Use timestamp in deposit data name to limit event log queries
• Use centralised service to keep track of deposits

[unixpi]

related https://github.com/ethereum/eth2.0-deposit/issues/41#issuecomment-626546164

[dankrad]

I absolutely agree that it would be a good idea to warn a user from the deposit interface, if possible. Was just pointing out that implementing that limit in the deposit contract would be the wrong way to do it.

[Battenfield]

I was under the impression that web3 did not support historical logs (beyond when you started watching), but I was mistaken. That said, there is a chance we run into the limits of a given web3 provider if the user is using one which has limits on the how many events can be returned (eg. Infura only returns 10000 events). That said, it is not my area of expertise, @Battenfield, can you weigh in on the feasibility of using myContract.events.allEvents([options][, callback]) with a filter on the pubkey?

We currently leverage events to pick up on signing and confirmations. However, I do not believe we can use web3 in this way for historical data.

As @Phistr90 points out, we have a few options for tracking deposit data:

• Use cookies / local deposit log

We explored this option early on for persisting data through refreshes and decided against it as it would be a form of tracking the user and unreliable. This option will not work when the user is on a different browser, rejected tracking, or if they did not use the launchpad to make their first deposit.

• Use timestamp in deposit data name to limit event log queries

@Phistr90 could you elaborate on this?

• Use centralised service to keep track of deposits

Unfortunately, our best option if our goal is to prevent users from depositing twice. We could use an external API to check their pubkey in the Transaction table step. If the user had previously deposited with that pubkey, we could render a warning to them. We could even block them and point them to the future topup feature in cause they were seeking that.

[Phistr90]

@Battenfield What I meant with Use timestamp in deposit data name to limit event log queries was that if we would use a service like infura to query events we likely would need to limit the scope of the query. The timestamp of the deposit data file could help limit that.