Proposal 23: Cheating relayers penalisation

Proposals
1

Context

This proposal serves to nullify the irretrievably deposited virtual balances of a number of relayers which exploit the current inability of frontends (due to the infeasibility of client side analysis, and the impossibility of keeping updated server side resources on IPFS deployments) to properly analyze relayers engaging in behaviour which encourages sybil-like attacks. This can be considered alike to a validator slashing mechanism.

Since there exists no circumstance within which relayers would not be informed of this (and relayers necessarily must be informed considering that they have to read documentation, and we also expect relayers to monitor community activity, meaning from their side out), Governance may understand this as unwanted behaviour and thus disincentivizes it from happening via nullifications until a better solution is achieved. The relayers have been via determined via programmatic methods.

Current state

At the moment, 8 relayer-cheaters with virtual balances larger than zero in staking have been identified:

  • moon-relayer.eth
    • 0x30F96AEF199B399B722F8819c9b0723016CEAe6C
  • official-tornado.eth
    • 0x5007565e69E5c23C278c2e976beff38eF4D27B3d
  • safe-tornado.eth
    • 0x2ffAc4D796261ba8964d859867592B952b9FC158
  • relayer-secure.eth
    • 0xCEdac436cEA98E93F471331eCC693fF41D730921
  • relayer-tornado.eth
    • 0xa42303EE9B2eC1DB7E2a86Ed6C24AF7E49E9e8B9
  • torn69.eth
    • 0x18F516dD6D5F46b2875Fd822B994081274be2a8b
  • 0xtorn365.eth
    • 0x065f2A0eF62878e8951af3c387E4ddC944f1B8F4
  • abracadabra-money-gone.eth
    • 0xb578603d3fb9216158c29488c1a902dd0300c115
    • More on this relayer below

Proposal

https://git.tornado.ws/Theo/proposal-23-cheating-relayer-penalisation

The code includes virtual balance nullifications of almost all cheating relayers and the transfer of their balances from the Staking contract to the Governance contract.

The only exception is the relayer abracadabra-money-gone.eth, whose owner contacted me over a week ago and said that all withdrawals through the tornado instance (rather than the router) were for testing purposes, and they represent less than 5% of the total withdrawals. I checked the transaction history of this relayer and came to the conclusion that compensation of all unpaid commissions in double amount will be enough, if this relayer continues to work honestly, as he did the whole previous year. Unpaid comission amount will be burned and distributed to stakers.

Why not burn all cheating relayers balances?

  1. Rewards from user withdrawals should be distributed to lockers. Staker balances are unallocated commissions, and burning all balances is not correct, because cheating relayers have not yet made enough transactions (and there are not enough unpaid commissions) to cover the entire balance of relayers.

  2. Burning all balances of cheating relayers will result in a one-time distribution of TORN as a reward among the stakers at the time of the proposal execution, which may allow an unscrupulous actor to lock a large amount of TORN in Governance without any risks right before the proposal is executed, then receive reward and unlock all tokens.

For community memebers

You have a day to discuss the proposal, exactly in 24 hours the proposal will be published in the blockchain and voting will be open.

8 Likes
3

Cheaters must be severely punished

4

I strongly support your proposal :+1:

6

I cannot agree with this for a number of reasons:

  1. We don’t manage third-party UIs, which are many at the moment - .eth.link, .eth.limo, 3th.ws and so on. Many of them, of course, receive data from IPFS, but they do not update the content hash. When resetting the balances of cheating relayers, they will not be visible on any of the comminuty sites, but if we just add them to the UI, this will not have an effect.
  2. There is no normal way to filter out cheating relayers.
    • The first option is to hardcode addresses or eth domains of cheaters - this will force IPFS to be updated using proposals to introduce new cheater addresses and, in addition, is bad programming practice;
    • The second option is to check all withdrawals via each relayer and check contract with which it interacts. At the moment we have more than 20 active relayers, for each one we will need to find a deployment block, and then check all transactions from it to the last block to see if they are cheating. Since it will be necessary to have up-to-date data, a new user (for example, who first accessed the site via IPFS) will be forced to fetch the entire cache for each relayer - let me remind you that the RPC limit is 1024 blocks at a time, more than 6,000 new blocks appear per day , all this will still need to be multiplied by twenty (by the number of relayers). It will be so long and inconvenient for users, especially if you do not frequently update the up-to-date cache on IPFS, that the idea does not stand up to criticism.
8

Proposal is live: https://tornado.ws/governance/23

1 Like
11

please add the lock function and increase the relayer registration threshold.
For 300 torn to be able to register a relayer, this threshold is obviously too low, which can be determined according to the liquidation cycle and torn price，currently for example, once a month can be 10,000 torn.

12

You may not have understood the actual situation yet. Currently, registration requires 2000Torn, and the minimum limit listed on the website is 500Torn. I don’t think the current minimum level can prevent cheating relayers. The minimum limit can be adjusted to over 1000

13

meaingless to play like that. it just limited / penalting the other relayer who didnt cheat. hex has a new solution in progress could solve this in new direction. which mean we have another choice to solve the problem without damage relayer benefit in future.

15

He thinks it’s a scam proposal. Change the rpc to see the text of the voice

17

Why is my staking reward data still 0 when the 23rd proposal passed?

21

must be punished strictly,…

1 Like