The Buy-A-Block Attack

An analysis of the vulnerabilities present in time dependent decentralized applications

The attack described below is a model that can be used to interact with time dependent decentralized applications. The attacker aim to spend money upfront in attempt to increase profit later on.

These examples below do not include analysis of shorting the coin (or buying Put Options) before implementing the attack. Shorting the dApps token would likely increase their profits.

Some Background Information:

Most Blockchains incentivize miners to validate transactions (so that people don’t spend money they don’t have — ie: double spend) using two types of fees:

1. Inflationary Reward — such as the block reward
2. Transaction Fees — fees generated by users to incentivize miners to prioritize their transaction in the block they are mining

Many blockchains put a limit on the size of a block. Either directly with 1MB Bitcoin Blocks or indirectly with a slowly moving limit such as Ethereum’s gas limit.

The Attack:

A decentralized application that requires some interaction within a set time period allows an attacker to completely fill the block with spam transactions so that the specified interaction does not take place. The attacker would pay a high fee (will be discussed in detail later) so that they are the only transaction(s) in the block.

A simple example:

To illustrate the attack in simple terms, below is an example.

Imagine we have a blockchain: Bob-chain with coin Bob-Coin

• Bob-chain has a limit of 1 MB of transactions per block

Bob-chain allows users to specify conditions in which the funds can be spent via scripts or/and smart-contracts (similar to Bitcoin or Ethereum). These conditions can be arbitrarily complex or as simple as a traditional p2p transaction.

Alice, deciding to be philanthropic, picks a random stranger’s wallet on the blockchain (Say Charlie’s wallet) and sends them 1000 Bob-Coin. However, she’s unsure about it, so she puts a condition, that in the next 5 blocks, she can retract the funds and Charlie will receive nothing.

Alice’s Philanthropic Transaction

Charlie now notices that there is a pending transaction given that Alice does not retract her money. Charlie would like to keep as much of the money as possible. Afraid Alice will retract the charity transaction, he is incentivized to figure out a way to block Alice from doing so.

Charlie figures that he bribe the miners indirectly to keep the blockchain full of spam transactions for the next five blocks, thus closing Alice’s retraction time window and ensuring he receives at least some funds.

Charlie spams the blockchain and gauruntees some charity money

If Charlie succeeds to fill the block (buying the block) for the next 5 blocks, he will walk away with the 1000 Bob-coins (subtract the fee used to pay to fill the block)

In practice it uncommon to find a transaction such as the above, but below are three use cases where developers need to be careful that they don’t create similar incentives.

Exitscam/FOMO3D Banner

Exitscam.me/FOMO3D:

TL;DR:

If the jackpot (right now 21,000 ETH) of Exitscam is greater than 24ETH and there is less than 10 minutes left, there is an opportunity to spend 24ETH on filling the Ethereum Blockchain with spam transactions and blocking other users from entering. The more time left, the more expensive it is to spam the blockchain. If the there is less than an hour left, there is an opportunity to spend 560 ETH to win the jackpot. If there is less than 10 hours left, there is an opportunity to spend 5600 ETH to win the jackpot.

The Rules:

Exitscam is a simple transparent pyramid scheme:

• Every round lasts some amount of time
• If you are the last person to put ETH into the pot, you take away the jackpot (~90% of ETH put in)
• If someone puts in ETH after you, you receive a dividend. Right now, less than 1% of ETH that has been sent to the contract has been paid out in dividends
• Every deposit .005 ETH (as of writing) adds 30 seconds (2 blocks) to the countdown clock (up to a maximum of 24 hours per purchase)

There are other rules that make it more nuanced and addictive that won’t be covered in this article.

The Strategy:

As the countdown clock approaches zero: deposit ETH, then buy every block until the countdown is over to ensure that nobody else can deposit after you.

If nobody else can deposit, you will win the jackpot.

The Math:

• current jackpot is J ETH
• max gas cost is around 8000000
• Blocks left until payout 38 (~9 minutes, 30 seconds) + 2 if you buy in (=40=~10minutes)

If J ETH is > 40 * 8000000 * E(gas_price) = 320,000,000 * E(gas_price)

J > 320,000,000 * E(gas_price)

Then we should buy into the jackpot and then buy the next ten blocks.

For this article, I will assume E(gas_price) could be done successfully with average + 4 standard deviations of the gas_price over the last 200 days. Data taken from EtherScan.

I find E(gas_price) = 7.337415102356531e-08 ETH (Script Here) so:

J > 23.5 ETH, would imply an opportunity to buy 10 blocks. More generally if there are N blocks left:

J > N * 2.35 ETH would imply an opportunity.

There are some complications in that others may see you doing the attack on the dApp and decide to spend more than you at the last moment. That analysis I will leave for another article.

Decentralized Oracles By Voting:

The Rules:

There is some event, E, that the system wants to determine the outcome from a choice of possible outcomes (say A, B, C).

The system will have users vote (stake) with their tokens for each possible choice. To prevent users from being dishonest, those who vote for the non-majority event will lose some (or all) of their staked coins.

The Strategy:

Buy every block so others can not vote about the outcome.

For example, lets say the attacker votes on the market: “Lebron James will be the MVP of this year’s NBA championship.” If he does become MVP, the attacker wins the bet, if he doesn’t become MVP, the attacker fills the blockchain during the voting process so that nobody can report that Lebron James did not win. Thus, the attacker will become the sole vote on the outcome and win the bet.

The attacker will fill the first block during the voting process with their vote for “Lebron James did become the MVP” and will continue to spam the blockchain so that nobody else can vote on the outcome.

The Math:

If the vote is going to last N blocks, as long as the profit of influencing the “Truth” is > C * N, an attacker should buy every block.

So What?

This puts a hard-limit on the size of any Oracle based dApp. Any app that needs information from the outside world (Thus, needing an Oracle) must give in on one of the following areas to have a safe environment from this attack:

1. Some control over the application to delay the end block for the vote (centralize control)
2. Some social consensus from the miners not to mine profitable transactions (utilitarian miners)
3. Keep the size capped so that sum of all possible profits is ≤ C * N (limit the size)

Keep in mind, that the 3rd solution doesn’t help if the malicious actor uses this to attack multiple dApps at the same time.

Decentralized Collateralized Lending

TL;DR:

Because crypto-assets are pseudo-anonymous, lending must be over-collateralized. If a borrower has a sufficiently large borrow that starts going against them, they should buy every block until it is unlikely that the cost will outweigh the possible gains.

The Rules:

1. Borrow one crypto-asset (say ETH) for another (say TUSD)
2. Collateralize the borrowed ETH by providing > 100% TUSD (TUSD is the margin/collateral)
3. As the price of ETH goes up, the platform issues a margin-call so that borrower needs to return some of the ETH or provide more TUSD (collateral) So that value of borrowed ETH < value of TUSD (collateral).

It is important to note that if we are doing decentralized pseudo-anonymous lending, there should be no credit-risk.

The key thing we’ll be focusing on is the margin-call.

To issue a margin call, some party needs to let the blockchain know the price has changed so that it can liquidate the TUSD into ETH so that the lender of the ETH does not lose value.

We will ignore:

1. How the liquidation from collateral (TUSD) into borrowed asset (ETH) works
2. How the protocol comes to consensus that the price has indeed gone up (Oracle based)

The Strategy:

If someone believes the price of an asset will be extremely volatile, there is an opportunity to make free money (arbitrage) by breaking the protocol if not application is not implemented correctly.

Suppose they believe ETH will move down relative to TUSD. They should borrow ETH using TUSD as collateral and sell the ETH on an exchange for TUSD. If the price goes down, they buy the asset for cheaper and return it (a normal short). If the price doesn’t move, just pay the interest. If the price goes up:

Block all margin calls by buying blocks to buy them more time for their position to become profitable

The Math:

If the probability that over one day the asset will become under-collateralized then into an over-collateralized position is P, the cost is C per block, with profits of W in a winning situation, then as long as E(C) ≤ W there is a winning strategy that includes buying all blocks until E(C) ≥ W.

E(C) = Cost per block * (discounting factor^i) * P(profit after i blocks); Summed from 1 to infinity.

Cost per block will always be relatively constant.

The constraint of how large W can be is directly proportional (in an exponential-like fashion) to P.

If the cost per block is 2.3 ETH (As discussed before) and the borrower has borrowed 50M USD worth of some asset, that is a cost of 0.00184% per block (at 400$/ETH). For Ethereum, thats 10.5984%/day. For a 500M borrow, thats just 1%/day. That is not a huge cost for such a devastating attack to the dApp.

Looking At Collateral:

The collateral on a borrow will be: (1 + X) * value of borrowed asset

If the volatility of the borrowed asset is high relative to X the change of success can be worth the risk.

Say we are borrowing asset A for asset B and the expected volatility is V% per day (drawn from a normal distribution) while the standard deviation is SD% per day.

We are trying to find the probability that the loan becomes under-collateralized: Z = (X - V)/SD, convert that to your z-table. P depends directly on X, V and SD. V and SD are market driven, so dApp creators and lenders do not have control, their only control is X.

I will end here without an analysis on why picking any sufficient X to keep lenders happy will likely leave all borrowers unhappy and X low enough to keep borrowers happy will leave lenders unhappy when they lose their money. In my opinion, which we’ll leave to another full article, decentralized lending will have difficulty competing with fully fledged centralized prime brokers.

Disclaimer:

Certain links, including links to other websites, are provided in this document. These links are provided as a convenience and do not imply the Kenneth Goodman’s sponsorship or approval of any of these websites or their content. Kenneth Goodman has no control over or responsibility for other websites that may be accessible from this website, the contents thereof, their security or privacy policies, or any products/services that may be offered by them. If you access any third party website through this document or its corresponding email through which you received this document, you do so at your own risk. Links to or from this document do not constitute an endorsement by Kenneth Goodman or the parties or businesses which are so linked, nor do they necessarily indicate any affiliation between Kenneth Goodman and such parties or businesses.

Kenneth Goodman is not a registered investment advisors and nothing in my article is intended, and it should not be construed, to be investment advice. Any material’s written here are for informational use only. Any mention of a security, commodity, derivative, index or other instruments is neither a recommendation to buy, sell or hold that asset, nor does it constitute an opinion by Kenneth Goodman to the suitability of that asset for any particular purpose.