This is our first draft of the proposal. We would love to get some comments on it. We’re also looking for contributors.
A copy of this will be on IPFS with the hash of Qmem2bje5QsYmiKv9HYMw8RE7EnCgDwRdb2qigSAjofaDk
Tornado cash improvement proposal
Author - yoyoismee.eth, unnawut.eth
We propose a new incentive scheme by allowing users to give bonuses to other users that perform deposit/withdrawal in a predefined period. With the aim to improve privacy, latency, usability, and capital efficiency by concentrating large amounts of tornado cash transactions into a small time window and subsidizing smaller users.
There’s 4 areas we want to address in this proposal namely. privacy, latency, usability, and capital efficiency
First and foremost privacy which is the core value of tornado cash. The system breaks the explicit link between the depositor wallet and withdrawer wallet. However, with the limited number of transactions in each period it’s still possible to associate the connection via some transaction analysis. Especially when moving large sums of money. The guideline recommended that users should wait at least 24hrs before withdrawing. But based on Fig1,2. there’s just at most north of 6k tx per month which is just around 200-300 txs per day and the volume of ~100M$ per day. To move any big sum of money relative to normal activity will significantly compromise anonymity. Also tracking, doxing, etc on a few hundred wallets wouldn’t be too hard.
Latency - the privacy of users is currently scale based on the amount of time between their deposit and withdrawal. Actually it scales on the number of other transactions in between but currently users have no control or influence over this. Hence waiting is the only option.
Usability - there’s 2 main concerns about this. One is cost, the gas required to perform a round trip is around 1.5M gas which might be a significant sum for some users. (especially when the gas is expensive). On the opposite end for whales, moving large sums though Torn is hard because the daily volume of transaction might not be enough to cover their track. This would result in whales having to move smaller amounts per day over a long period of time.
Capital efficiency - the current TVL of torn is over 200K ETH and 300M$. (Fig 3,4) This capital is sitting there to provide some cover for other users and maybe to mine torn. However, there is a more efficient way to do this.
We propose a lightweight contract that allows users to incentivise others to perform certain actions in a certain interval. And allow users to use a spent ticket to claim the bonus. The second part should behave similar to anonymity mining
createBounty(address contract , uint256 reward, uint firstDepositBlock, uint lastDepositBlock, uint firstWithdrawBlock, uint lastWithdrawBlock, uint deadlineBlock) payable
- Address contract -> target contract to interact with (torn contract)
- Uint reward -> eth reward per transaction
- Uint firstDepositBlock -> valid ticket must deposit after this block
- Uint lastDepositBlock -> valid ticket must deposit before this block
- Uint firstWithdrawBlock -> valid ticket must withdraw after this block
- Uint lastWithdrawBlock -> valid ticket must withdraw before this block
- Uint deadlineBlock -> must claim reward before this block. require(deadlineBlock > lastBlock + buffer)
Behavior - this function will create a reward pool of the input spec together with msg.sender as owner and msg.value as pool size.
- BountyCreated(Uint bountyId) -> ID of the bounty pool
- Uint bountyID - ID of the bounty pool
Behaviour - require block.number >= deadlineBlock. Send the remaining reward back to the pool creator.
reward(uint bountyId, bytes memory _proof, _args)
- Uint bountyId -> ID of the bounty pool that the user wishes to claim.
- The rest are the same as anonymity mining
Behaviour - User can submit a valid spent ticket to claim the reward. This is similar to Anonymity Mining’s claim behavior except that the Anonymity Points received is constant regardless of how long the tokens stayed in the pool, and an extra check that the deposit/withdrawal happened within the bounty period.
withdraw(bytes _proof, (uint256 amount, bytes32 extDataHash, tuple extData, tuple address))
- Same as the original Anonymity Mining’s parameters
Behaviour - User converts the Anonymity Points into actual bounty rewards. This behaves the same as the original Anonymity Mining except that the reward is in ETH instead of TORN.
To invade user privacy by using data analytic. The attacker will try to analyze different aspects of the activity to find a pattern. A common way to view this is through the concept of signal to noise ratio aka how standout a thing is from the rest. And our privacy is as bad as the most obvious signal to noise that we give out.
To elaborate on this. Let’s use water as our analogy. Let’s say we have a massive lake (TVL), another bucket of water there wouldn’t be obvious to anyone. However, if on a certain day there’s only a few villagers taking from the lake. It would be quite easy to spot and track down. This is what happened to torn right now, 200 txs per day isn’t enough.
On the other hand if there’s low TVL let’s say a small tub with let’s say 5 people worth of water at a time. Even if a lot of users cycle through it. It is still not too hard to associate who is who. But this isn’t our problem right now.
The other way is just based on pattern. Let’s say someone does it in a certain time, certain interval, where it goes afterward, etc. all of this pattern can be used against our privacy.
There’s so many other signals that we create everytime we do or do not do something. Everything can be used to isolate a user from the rest of the pool.
Our rationale is instead of letting each user try to minimize their signal. It would be easier to just maximize noise in a certain time and use that period to cover everybody’s track.
So let’s say we have a small pond but someone gives certain $ to anyone who puts water in or takes water out. With the right price. We’ll have a massive mob of people doing interaction with it. Small pond might become a giant lake. A giant lake might dry up. Or a quiet town might experience a brief moment of massive tornado storm surging through. This massive noise and anomaly pattern would be a significantly harder pattern to analyze. A bottle, a whole truck, how many times it changes hands will probably not mattern much in the middle of a storm isn’t it?
Another side effect of this is. The capital doesn’t have to sit in Torn all the time. It can move around doing something productive. This would make most wallets look more alive and harder to analyze too.
For whales. This would make things a lot easier and faster. The whole experience is just like paying an extra fee for it.
For small users. This makes torn more accessible or even profitable. We expect this to open Torn up to an even wider user base.
For bot operators (new player for Torn). This is just another profitable risk free action that they can take on.
For the community as a whole. This would improve overall privacy for everyone.
For privacy invaders, welp tough luck. they can try to cope with new mechanics that can alter data patterns and a few new players in the game. But given that we have a new tool to mess with them now it’s an arms race. (not just them trying to spy on others people)
Expected bonus price - assuming that a round trip cost would be lower than 0.2 eth. (1.5M gas + maybe send eth a few time + claim reward). While ETH risk free return right now is single digit APR. which is like 0.02% per day. So I would expect any bonus over 0.2 + 0.02% of ticket size * days + some bonus would be enough to get a profit seeker to join the party.
And For users who might wanna move funds, any bonus more than claiming cost is already net positive.
Fig 2-4 are not available due to the forum limitations on media. pls view the full version on IPFS
Fig 1 Torn monthly withdrawal (transaction)
Fig 2 Torn deposit/ withdraw (value)
Fig3 ETH locked in Torn
Fig 4 USD locked in Torn