Storm Surge Proposal: an improvement on private, latency, usability, and capital efficiency to tornado cash

Author note:

This is our first draft of the proposal. We would love to get some comments on it. We’re also looking for contributors. :slight_smile:

A copy of this will be on IPFS with the hash of Qmem2bje5QsYmiKv9HYMw8RE7EnCgDwRdb2qigSAjofaDk

—----

Storm Surge

Tornado cash improvement proposal

Author - yoyoismee.eth, unnawut.eth

Simple Summary

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.

Motivation

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.

Specification

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

Param

  • 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.

Events

  • BountyCreated(Uint bountyId) -> ID of the bounty pool

withdrawBounty(uint bountyId)

Param

  • 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)

Param

  • 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))

Param

  • 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.

Rationale

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.

Stakeholder analysis

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)

Appendix

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.

Figure

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

6 Likes

Could you accomplish the same goals by implementing a new kind of withdrawal relayer? From a user-interface point of view, the best way to convince me to withdraw some funds I might have sitting in Tornado (or to deposit then withdraw some) would be being able to choose a relayer that paid me when withdrawing, in whatever tokens I was withdrawing (I don’t want to think about TORN, make it simple, please).

I’m imagining a whale spinning up a relayer that maybe rewards 0.01 ETH (or whatever) for the first 50 100ETH withdrawals over some short time period. They’d fund it with 0.5 ETH (plus enough ETH for 50 withdrawal transaction fees), and mix in their withdrawals (so some of that ETH would go back to them).

But you’d run into the same problem we had with anonymity mining: people depositing then withdrawing just to get the incentive, not contributing to privacy at all. I haven’t heard any good solutions to that problem (simple suggestions like “just don’t reward withdrawals to addresses that were used for deposits” are too easy to work around). Even a strict rule like “you only get rewarded if you withdraw to a brand-new address” won’t work, because nothing stops somebody from later sending the funds from that new address back to the original deposit address, removing that deposit/withdraw from the anonymity set.

3 Likes

thanks for the comments.

relayer is also one of the ideas that we briefly explore but we drop it early on in favour of the modified AM for more flexibility (but kinda harder for users) we would love to discuss the possibility of using an incentivised relayer too. I think it might work but I have some concerns over a potential risk about routing a lot of traffic into one relayer. it might become an attack surface. (e.g. some malicious actor might try to use this mechanic to incentivize lotta users to their’s and maybe do something with it) and I totally understand the concern about TORN. A simple denominated token would be easier for most users.

on the challenge of AM - we try to address some issues. I think some of the newly introduced parameters/mechanics might help.

  • the ability to control the deposit/withdrawal period should protect against looping through torn multiple times which is not too useful on anonymity. (people can do it at most 1 cycle per bounty)
  • the reward can be set to be high or low. if lower than gas. and the full loop results in net loss for the user. this would guarantee that this is no profit seeker in this and hopefully all user are real users who really wants anonymity.(aka basically just a subsidise not a bribe)
  • given that the reward is based on a round trip instate of how long it sits in the pool. this would encourage people to use their capital elsewhere (to fully utilize their capital) so this might make more wallets that interact with TORN look more alive.

yeah. long way to go for us. need more brain on this lol

Nice to have you here yoyoismee and showing an interest in contributing to tornado. I love the theory you have formed around boosting anonymity and decorrelating the ability to profile transactional behavioral patterns by clustering deposits together. Funnily enough, the team who built tutela use a cluster methodology to build links between multiple wallets that use tornado to quantify an actor’s level of anonymity.

I personally do think there is a possibility of an incentive scheme, that rewards proficient depositors over those who game it. Although, right now I think the only way to potentially minimise gamification is by a) defining rewards over a relatively large timescale (epochs) b) deriving rewards by how adept a individuals destination address is for the best privacy practices.

Obviously, b can’t be achieved in a permissionless fashion but a potential snapshot of withdrawals could be orchestrated within the epoch to quantify each actor’s anonymity through tutela’s ongoing work on creating an “anonymity score”, and rewards actors based on this.

I like your approach towards this idea, is not a protocol-level incentive but instead a user-end incentive, allowing one to reap more efficiency by incentivising others if they are a profilic actor. I hope you guys continue to brainstorm to solve this pitfall of anonymity mining.

1 Like