Month: May 2024

Understanding Tornado Cash: code as speech vs code in action

Tornado Cash is a mixer on the Ethereum network. By design mixers obfuscate the movement of funds. They make it more difficult to trace how money is flowing among different blockchain addresses. In one view, mixers improve privacy for law-abiding ordinary citizens whose transactions are otherwise visible for everyone else in the world to track. A less charitable view contends that mixers help criminals launder the proceeds of criminal activity. Not surprisingly Tornado found a very happy customer in North Korea, a rogue nation-state with a penchant for stealing digital assets in order to evade sanctions. Regulators were not amused. Tornado Cash achieved the dubious distinction of becoming the first autonomous smart-contract to be sanctioned by the US Treasury. Its developers were arrested and put on trial for their role in operating the mixer. (One has already been convicted of money laundering by a Dutch court.)

Regardless of how Tornado ends up being used in the real world, lobbying groups have been quick to come to the defense of its developers. Some have gone so far as to cast the prosecution as an infringement on constitutionally protected speech, pointing to US precedents where source code was deemed in scope of first amendment rights. Underlying such hand-wringing is a slippery slope argument. If these handful of developers are held liable for North Koreans using their software to commit criminal activity, then what about the thousands of volunteers who are publicly releasing code under open-source licenses? It is almost certain that somebody somewhere in a sanctioned regime is using Linux to further the national interests of those rogue states. Does that mean every volunteer who contributed to Linux is at risk of getting rounded up next? 

This is a specious argument. It brushes aside decades of lessons learned from previous controversies around DRM and vulnerability disclosure in information security. To better understand where Tornado crosses the line, we need to look at the distinction between code as speech and code in action.

“It’s alright Ma— I’m only coding”

There is a crucial difference between Tornado Cash and the Linux operating system, or for that matter open-source applications such as the Firefox web browser. Tornado Cash is a hosted service. To better illustrate why that makes a difference, let’s move away from blockchains and money transmission, and into a simpler setting involving productivity applications. Imagine a not-entirely-hypothetical world where providing word processing software to Russia was declared illegal. Note this restriction is phrased very generically; it makes no assumptions about the distribution or business model.

For example the software could be a traditional, locally installed application. LibreOffice is an example of an open-source competitor to the better-known MSFT Office. If it turns out that somebody somewhere in Russia downloaded a copy of that code from one of the mirrors, are LibreOffice developers liable? The answer should be a resounding “no” for several reasons. First the volunteers behind LibreOffice never entered into an agreement with any Russian national/entity for supplying them with software intended for a particular purpose. Second, they had no awareness much less control over who can download their work product once it is released into the wild. Of course these points could also be marshaled in defense of Tornado Cash. Presumably they did not run a marketing campaign courting rogue regimes. Nor for that matter, did North Korean APT check-in with the developers first before using the mixer— at least, based on publicly known information about the case. 

But there is one objection that only holds true for the hypothetical case of stand-alone, locally installed software: that source-code downloaded from GitHub is inert content. It does not accomplish anything, until it is built and executed on some machine under control of the sanctioned entity. The same defense would not hold for a software-as-a-service (SaaS) offering such as Google Docs. If the Russian government switches to Google Docs because MSFT is no longer allowed to sell them copies of Word, Google can not disclaim knowledge of deliberately providing a service to a sanctioned entity. (That would hold true even if use was limited to the “free” version, with no money changing hands and no enterprise contract signed.) Google is not merely providing inert lines of code to customers. It has been animated into a fully functioning service, running on Google-owned hardware inside Google-owned data-centers. There is every expectation that Google can and should take steps to limit access to this service from sanctioned countries.

While the previous cases were cut and dry, gray areas emerge quickly. Suppose someone unaffiliated with the LibreOffice development team takes a copy that software and runs it on AWS as a service. With a little work, it would be possible for anyone in the world with a web browser to remotely connect and use this hosted offering for authoring documents. If it turns out such a hosted service is frequented by sanctioned entities, is that a problem? Provided one accepts that Google bears responsibility for the previous example, the answer here should be identical. But it is less straightforward who that responsible party ought to be. There is full separation of roles between development, hosting and operations. For Google Docs, they are all one and the same. Here code written by one group (open-source developers of LibreOffice) and runs on physical infrastructure provided by a different entity (Amazon.) But ultimately it is the operator who crossed the Rubicon. It was their deliberate decision to execute the code in a manner that would make its functionality publicly-accessible, including to participants who not supposed to have access. Any responsibility from misuse then lies squarely with the operator. The original developers are not involved. Neither is AWS. Amazon is merely the underlying platform provider, a neutral infrastructure that can be used for hosting any type of service, legal or not.

Ethereum as the infrastructure provider

Returning to Tornado Cash, it is clear that running a mixer on ethereum is closer in spirit to hosting a service at AWS, than it is to publishing open-source software. Billed as the “world computer,” Ethereum is a neutral platform for hosting applications— specifically, extremely niche types of distributed application requiring full transparency and decentralization. As with AWS, individuals can pay this platform in ether to host services— even if those services are written in an unusual programming language and have very limited facilities compared to what can be accomplished with Amazon. Just like AWS, those services can be used by other participants with access to the platform. Anyone with access to the blockchain can leverage those services. (There is in some sense a higher bar. Paying transaction fees in ether is necessary to interact with a service on the Ethereum blockchain. Using a website hosted at AWS requires nothing more than a working internet connection.) Those services could be free or have a commercial angle— as in the case of the Tornado mixer, which had an associated TORN token that its operators planned to profit from.

The implication is clear: Tornado team is responsible for their role as operators of a mixing service, not for their part developers writing the code. That would have been protected speech if they had stopped short of deploying a publicly-accessible contract, leaving it in the realm of research. Instead they opted for “breathing life into the code,” by launching a contract, complete with a token model they fully controlled.

One key difference is the immutable nature of blockchains: it may be impossible to stop or modify a service once it has been deployed. It is as if AWS allowed launching services without a kill switch. Once launched, the service becomes an autonomous entity that neither the original deployer or Amazon itself can shut down. But that does not absolve the operator of responsibility for deploying the service in the first place. There is no engineering rule that prevents a smart-contract from having additional safeguards, such as the ability to upgrade its code to address defects or even to temporarily pause it when problems are discovered. Such administrative controls— or backdoors, depending on perspective— are now common practice for critical ethereum contracts, including stablecoins and decentralized exchanges. For that matter, contracts can incorporate additional rules to blacklist specific addresses or seize funds in response to law enforcement requests. Stablecoin operators do this all the time. Even Tether with its checkered history has demonstrated a surprising appetite for promptly seizing funds in response to court orders. The Tornado team may protest they have no way to shut down or tweak the service in response to “shocking” revelations that it is being leveraged by North Korea. From an ethical perspective, the only response to that protest is: they should have known better than to launch a service based on code without adequate safeguards in the first place.

Parallels with vulnerability disclosure

Arguments over when developers cross a line into legal liability is not new. Information security has been on the frontlines of that debate for close to three decades owing to the question of proper vulnerability disclosure. Unsurprisingly software vendors have been wildly averse to public dissemination of any knowledge regarding defects in their precious products. Nothing offended those sensibilities more than the school of “full disclosure” especially when accompanied by working exploits. But try as they would like to criminalize such activity with colorful yet misguided metaphors (“handing out free guns to criminals!”) the consensus remains that a security researcher purely releasing research is not liable for the downstream actions of other individuals leveraging their work— even when the research includes fully weaponized exploit code ready-made for breaking into a system. (One exception has been the content industry, which managed to fare better, thanks to a draconian anti-circumvention measure in the DMCA. While that legislation certainly had a chilling effect on pure security research on copyright protection measures, in practice most of the litigation has focused on going after those committing infringement rather than researchers who developed code enabling that infringement.) 

Debates still continue around what constitutes “responsible” disclosure, where society can strike the optimal balance between incentivizing vendors to fix security vulnerabilities promptly without making it easier for threat actors to exploit those same vulnerabilities. Absent any pressure, negligent/incompetent vendors will delay patches arguing that risk is low because there is no evidence of public exploitation. (Of course absence of evidence is not evidence of absence and in any case, vendors have little control over when malicious actors will discover exploits independently.) But here we can step back from the question of optimal social outcomes, and focus on the narrow question of liability. It is not the exploit developer writing code but the person executing that exploit against a vulnerable target who ought to be held legally responsible for the consequences. (To paraphrase a bumper-sticker version of second amendment advocacy: “Exploits don’t pop machines; people pop machines.”) In the same vein, Tornado Cash team is fully culpable for their deliberate decision to turn code into a service. Once they launched the contract on chain, they were no longer mere developers. They became operators.

CP

Behavioral economics on Ethereum: stress-testing censorship resistance

Predicated on studying the behavior of real people (distinct from the mythical homo economicus of theory) behavioral economics has the challenge of constructing realistic experiments in a labarotory setting. That calls for signing up a sizable group of volunteers and putting them into an artificial situation with monetary incentives to influence their decision-making process. Could blockchains in general and Ethereum in particular help by making it easier to either recruit those participants or setup the experimental framework? In this blog post we explore that possibility using a series of hypothetical experiments, building up from simple two-person games to an open-ended version of the tragedy of the commons.

1. Simple case: the ultimatum game

The ultimatum game is a simple experiment involving two participants that explores the notion of fairness. The participants are randomly assigned to either “proposer” or “responder” role. A pool of funds is made available to the proposer, who has complete discretion on making an offer to allocate those funds between herself and the responder. If the responder accepts, the funds are distributed as agreed. If the responder vetos the offer— presumably for being too skewed towards the proposer— no one receives anything.

This experiment and its variations are notable in showing an unexpected divergence from the theoretical “profit maximization” model of economics 101. Given that the responder has no leverage, one would expect they will begrudgingly settle for any amount, including wildly unfair splits where the proposer decides keeps 99% of the funds. Given that the proposer is also a rational actor aware of that dynamic, the standard model predicts such highly uneven offers being made… and accepted. Yet that is not what experiments show: most offers are close to 50/50 and most responders outright reject offers that are considered too unequal. (This only scratches the surface of the complex dynamics revealed in the experiment. Subtle changes to the framing— such as telling the responders a tall tale about the split being randomly decided by a computer program instead of a sentient being— changes their willingness to accept unfair splits; possibly because one does not take “offense” at the outcome of a random process the same way they might react to the perceived greed of the fellow on the other side.)

Putting aside the surprising nature of the results, it is straightforward to implement this experiment in Ethereum. We assume both the proposer and responder have ethereum wallets with known addresses. In order to run the experiment on chain, researchers can deploy a smart-contract and fund it with the promised reward. This contract would have three functions:

  1. One only callable by the proposer, stating the intended allocation of funds.
  2. One only callable by the responder, accepting/rejecting that proposed allocation. Depending on the answer, the contract would either distribute funds or return the entire amount back to the experiment team. 
  3. For practical reasons, one would also include an escape-hatch in the form of a third function that can be called by anyone after some deadline has elapsed to recover the funds in case one or both subjects fail to complete the expected task. Depending on the which side reneged on their obligation, it would award the entire reward to the other participant.

There are some caveats that could influence the outcome: both participants must hold some ether already at their designated address, in order to make smart-contract calls. Alternatively the experimenters can supply just enough ETH to both volunteers to pay for the expected cost of those calls. But that runs the risk of participants deciding to abscond with funds instead of proceeding with the experiment. (The responder in particular faces an interesting dilemma when confronted with an unfair split they are inclined to reject. On the one hand, registering their displeasure on-chain sends a message to the greedy proposer, at the cost of spending ETH they had been given for the experiment. On the other hand, simply transferring that ETH to a personal wallet allows the proposer to walk away with something but only at the cost of allowing the greedy proposer to keep 100% of the funds due to the assumed default.) This effect is diminished to the extent that the prize money up for grabs is much larger than the transaction fees the participants are required to part with. More generally, transaction fees determine whether running this experiment on-chain would be any more efficient from an experimental stance than enticing volunteers with free food.

More subtle is the effect of perceived privacy— or lack thereof— in influencing participant behavior. Would a proposer be less inclined to reveal their true colors and offer an unfair split when interacting on-chain versus in real life? On the one hand, blockchains are public: anyone can observe that a particular proposal was greedy. Having their actions permanently on the record for the whole world to observe may motivate participants to follow social mores. On the other hand, blockchain addresses are pseudonyms, without any identifying information. “Bravery of the keyboard” may result in fewer inhibitions about diverging from social expectations and making greedy offers when one is not directly interacting with other persons.

2. Open to all: the Ether auction

The ultimatum game is played between two players. Running that experiment still requires finding suitable volunteers, pairing them up and launching a smart-contracts for each pair. (The contract will only accept inputs from the proposer and responder, and as such must have awareness of their address.) But there are other experiments which can be run without requiring any advance coordination, beyond that of publicizing the existence of a smart-contract that implements the experimental setup. In effect anyone with an ethereum wallet can make an independent decision on whether they want to participate.

Tullock auctions in general and the better-known “dollar auction” in particular are a case in point. As with all auctions, the highest bidder wins by paying their offer. But unlike most auctions, everyone else who loses to that winning bid are still required to part with the amount they offered. Given those unforgiving dynamics— everyone except the winner must pay and still end up with nothing in return— it seems illogical that anyone would play along. Now consider the “dollar auction,” a slight variant that is simple enough to be demonstrated in classroom settings. The professor holds up a $100 bill and offers to give it to the highest bidder, subject to Tullock auction rules with $1 increments for bids. (Side note: in the original version, only the second-highest bidder is forced to pay while all others are spared. That still does not alter the underlying competitive dynamic between the leading two bidders.) Once the students get over their sense of disbelief that their wise teacher— economics professor by training, of all things—  is willing to part with a $100 bill for a pittance, this looks like a great deal. So one student quickly comes up with the minimum $1 bid, spotting an easy $99 profit. Unfortunately the next student sees an equally easy way to score $98 by bidding $2. Slightly less profit than the first bidder imagined achieving if they remained uncontested, but still a decent amount that any rational participant would rightfully chase after. It follows that the same logic could motivate fellow students to bid $3, $4 and higher amounts in an ever increasing cycle of bids. But even before the third student jumps in, there is one person who has suddenly become more motivated to escalate: the initial bidder. Having lost the lead, they are faced with the prospect of losing $1— since everyone must pay their bid, win or lose. That fundamentally alters their expected value calculus, compared to other students currently sitting on the sidelines. A student who has not entered the auction must decide between zero gain (by remaining a spectator in this experiment) or jumping into the fray to chase after the $100 being dangled in front of the class. By contrast a student who has been already out-bid is looking at a choice between a guaranteed loss of their original or escalating the bid to convert that losses into gains.

Informally these auctions distill the notion of “arms race” or “winner-take-all” situations, where multiple participants expend resources chasing after an objective but only one of them can walk away with the prize while everyone else sees their effort wasted. Economists cited examples where such dynamics are inadvertently created, for example in the competition between American cities competing to win HUD grants. (Presumably the same goes for countries making elaborate bids to host the next Olympics or FIFA World Cup, considering that only one of them will be granted the opportunity.)

Shifting this classroom exercise into Ethereum is straightforward: we create a smart-contract and seed it with the initial prize money of 1 ETH. The contract accepts bids from any address, provided it exceeds the current leading bid by some incremental amount. In fact the bid can be automatically deduced from the amount of ether sent. Participants do not need MetaMask or similar noncustodial wallets with contract invocation capabilities. They can simply send ETH to the contract from an online centralized exchange. Contracts can be design with a default payment function that is triggered when any ether is sent, even without an explicit function call. That default fallback function can take care of the book-keeping associated with bids, including distinguishing between initial vs updated bids. If an address was encountered before, any subsequent calls with value attached are considered an increment on top of the original bid. (That is, if you bid 0.5 ETH and now want to raise that offer to 0.7ETH in order to counter someone else bidding 0.6 ETH, your second call only need to attach the delta 0.2 ETH.) At some previously agreed upon block-height or time, the contract stops accepting any more bids. The same fallback function can be invoked by anyone to “finalize” the outcome and send the prize money to the winner, and presumably any left over ETH from incoming bids to a GoFundMe campaign for funding behavioral economics education.

While this seems straightforward, there are some subtle differences from the class-room setting due to the way Ethereum operates. These can distort the auction dynamics and create alternative ways to maximize profit. The most problematic one arises from the interaction of an auction deadline with the block-by-block manner ethereum transactions are added to the blockchain. One way to guarantee not being outbid is to make sure one is submitting the last bid. If the auction is set to conclude at a particular block height or even instance in time (ethereum blocks contain a timestamp) all rational actors would engage in a game of chicken, waiting until that last block to submit their bids.

In fact, since transactions are visible in mempool before they are mined, rational actors would continue to bide there time even during the interval for that block. Optimal strategy calls for waiting out other bidders to send their transactions, and only submit a higher bid after all of those suckers prematurely tipped their hand. Naturally this runs a different risk that the bid may arrive too late, if the block has already been constructed and attested without your bid getting the last laugh. (That also raises a question of what the contract should do with bids arriving after the deadline. It can bounce the ETH as a favor to the slow poke or alternatively, eat up the ETH without taking the bid into consideration as punishment for playing this game of chicken.)

Even this model is too simplistic for not taking MEV into account. Ethereum blocks are not simply constructed out of some “fair” ordering of all public transactions sitting around in the mempool according to gas paid. Miners have been operating a complex ecosystem of revenue optimization by accepting out-of-band bids— that is, payment outside the standard model of fees— to prioritize specific transactions or reorder transactions within a block. (This system became institutionalized with the switch to proof-of-stake.) Why would participants compete over ordering within a block? Because transactions are executed in the order they appear in the block, and there may be a significant arbitrage opportunity for the first mover. Suppose a decentralized exchange has temporarily mispriced a particular asset because the liquidity pools got out of balance. One lucky trader to  to execute a trade on that DEX can monopolize all of the available profit caused by the temporary dislocation. If the competition to get that transaction mined first were conducted out in the open— as the fee marketplace originally operated— the outcome would be a massively wasteful escalation in transaction fees. Those chasing the arbitrage opportunity would send transactions with increasing fees to convince miners to include their TX ahead of everyone else in the block. This is incredibly inefficient: while multiple such transactions can and will be included in the next block, only the earliest one gets to exploit the price discrepancy on the DEX and collect the reward, while everyone else ends up wasting transaction fees and block space for no good reason. If that dynamic sounds familiar, it is effectively a type of Tullock auction conducted in mempool.

MEV solves that problem by having market participants submit individual transactions or even entire blocks to miners/validators through a semi-private interface. Instead of competing with each other out in the open and paying for TX that did not “win” the race to appear first, MEV converts the Tullock auction into a garden-variety sealed bid first price auction where the losers are no longer stuck paying their bid.

By the same logic, MEV provides a way out of the bizarre dynamics created by the Ether auction: instead of publicly duking it out with bids officially registered on-chain or even sitting in mempool, rational participants can use a service such as Flashbots to privately compete for the prize. There is still no guarantee of winning— a block proposer could ignore Flashbots and just choose to claim the prize for themselves by putting their own bid TX first— but MEV removes the downside for the losers.

3. Tragedy of the commons: Luring Lottery

Here is a different experiment that MEV will not help with. For real life inspiration, consider an experiment Douglas Hofstadter ran in Scientific American in 1983. (Metamagical Themas covers this episode in great detail.) SciAm announced a lottery with a whopping million dollar bounty to be awarded to the lucky winner. The rules were simple enough: any one can participate by sending a postcard with a positive integer written on the card. Their odds of winning are proportional to the submitted number. There is one catch: the prize money is divided by the total of all submission received. In the “best case” scenario— or worst case, depending on the publisher perspective— only one person participates and sends in the number 1. At that point SciAm may be looking at chapter 11, because that lucky reader is guaranteed to collect the promised million dollars. Alternatively in a “worst case” scenario, millions of readers participate or a handful of determined contestants submit astronomically large numbers to win at all costs. SciAm lives to publish another issue, as the prize money is diluted down to a few dollars.

Unlike the dollar auction, there is nothing subtle about the dynamics here. The contest is manifestly designed to discourage selfish behavior: submitting large numbers (or even making any submission at all, since a truly altruistic reader could deliberately opt not to participate) will increase individual chances of winning, but reduce the overall prize. While the magazine editors were rightfully concerned about having to payout a very large sum if most readers did not take the bait, Hofstadter was not flustered.

No one familiar with Garrett Hardin’s fundamental insight in “The tragedy of the commons” will be surprised by what transpired: not only were there plenty of submissions, some creative readers sent entries that were massive— not expressed as ordinary numbers but defined with complex mathematical formulas, to the point where the contest organizers could not even compare these numbers to gauge probabilities. Not that it mattered, as the prize money was correspondingly reduced to an infinitesimal fraction of a penny. No payouts necessary.

Again this experiment can be run as an Ethereum smart-contract and this time MEV will not help participants game the system. As before, we launch a contract and seed it with the prize money ahead of time. It has two public functions:

  • One accepts submissions for a limited time. Unlike the SciAm lottery judged by sentient beings, we have to constrain submissions to actual integers (no mathematical formulas) and restrict their range to something the EVM can comfortably operate on without overflow, such as 2200. Any address can submit a number. They can even submit multiple entries; this was permitted in the original SciAm lottery which serves as the inspiration for the experiment. The contract keeps track of totals submitted for each address, along with a global tally to serve as denominator when calculating winning odds for every address.
  • The second function can be called by anyone once the lottery concludes. It selects a winner using a fair randomness source, with each address weighted according to the ratio of their total submissions to the overall sum. It also adjusts the payout according to the total submissions and sends the reward to the winner, returning the remainder back to the organizers. (Side note: getting fair randomness can be tricky on chain, requiring a trusted randomness beacon. Seemingly “random” properties such as the previous block hash can be influenced by participants trying to steer the lottery outcome to favor their entry.)

Given this setup, consider the incentives facing every Ethereum user when the lottery is initially launched. There is a million dollars sitting at an immutable contract that is guaranteed to pay out the prize money according to predefined rules. (Unlike SciAm, the contract can not file for bankruptcy or renege on the promise.) One call to the contract is all it takes to participate in the lottery. Win or lose, there is no commitment of funds beyond the transactions fees required for that call. This is a crucial difference from the Tullock auction where every bid represents a sunk cost for the bidder. Downsides are capped regardless of what other network participants are doing.

Also unlike the Tullock auction, there is little disincentive to participate early. There is no advantage to be gained by waiting until the last minute and submitting the last entry. Certainly one can wait to submit a number much higher than previous entries to stack the odds, but doing so also reduces the expected payout. Not to mention that since submissions are capped in a finite range, participants can simply submit the maximum number to begin with. Meanwhile, MEV can not help with the one problem every rational actor would like to solve: prevent anyone else from joining the lottery. While it would be great to be the only participant or at least one of a handful of participants with an entry, existing MEV mechanisms can not indefinitely prevent others from participating in the lottery. At best bidders could delay submissions for a few blocks by paying to influence the content of those blocks. It would require a coordinated censorship effort to exclude all transactions destined to the lottery contract for an extended period of time.

If anything MEV encourages early participation. No one can be assured they will have the “last say” in the construction of the final block before the lottery stops accepting submissions. Therefore the rational course of action is to submit an entry earlier to guarantee a chance at winning. In fact there may even be optimal strategies around “spoiling” the payout for everyone else immediately with a large entry, such that the expected reward for future entries is barely enough to offset transaction fees for any future participant. This is an accelerated tragedy of the commons— equivalent to the herdsmen from Hardin’s anecdote burning the grasslands to discourage other herdsmen from grazing their cattle on the same land.

Testing censorship resistance

Alternatively the ether auction and Luring Lottery serve as empirical tests of miner censorship on Ethereum. In both cases, rational actors have a strong incentive to participate themselves while preventing others from participating. This is because participation by others reduces the expected gain. For the ether auction, being outbid results in going from guaranteed profit to guaranteed loss. For the Tullock lottery, competition from other participants is not quite as detrimental but it undermines expected return in two ways: by reducing the probability of winning and slashing the prize money on offer. It follows that rational actors have an incentive to censor transactions from other participants.

If 100% reliable censorship is possible, then both experiments have a trivial winning strategy for the censor. For the Tullock auction, submit the minimum acceptable bid and prevent anyone else from making higher offers. Likewise for the Luring Lottery, send the number “1” and block anyone else from submitting an entry that would dilute the prize money.

On Ethereum, block proposers are in the best position to engage in such censorship at minimal cost. While they would be foregoing fees associated with the censored TX, that loss is dwarfed by the outsized gain expected from monopolizing the full rewards available from the hypothetical contract. Could such censorship be sustained indefinitely? This seems unlikely, even if multiple validators were colluding under an agreement to split the gains. It only takes a defection from a single proposer to get a transaction included. Validators could choose to pursue a risky strategy of ignoring the undesirable block, on the pretense that the proposer failed to produce a block in time as expected. They could then wait for a block from the next “compliant” proposer who follows the censorship plan. This approach will fail and incur additional penalties if other attesters/validators accept the block and continue building on top of it. Short of near universal agreement on the censorship plan— as with OFAC compliance— a coalition with sufficient validator share is unlikely to materialize. On the other hand 100% reliable censorship is not necessary for the Luring lottery: block proposers can not stop other proposers from participating when it is their turn, but they can certainly exclude any competing TX from their own blocks. That effectively limits participation to proposers or at best ethereum users aligned with a friendly proposer willing to share the prize. But such tacit collusion would be highly unstable: even if every proposer correctly diagnosed the situation and limited themselves to a single submission of “1” to avoid unnecessary escalation, there would still be an incentive to rig the lottery with a last-minute submission that dwarfs all previous entries. 

CP

[Edited: May 4th]