May 24, 2024

Why ASICs may be good for Bitcoin

Bitcoin mining is now almost exclusively performed by Bitcoin-specific ASICs (application-specific integrated circuits). These chips are made by a few startup manufacturers and cannot be used for anything else besides mining Bitcoin or closely related cryptocurrencies [1]. Because they are somewhere between a thousand and a million times more efficient at mining Bitcoin than a general-purpose computer that you can buy for the same price, they have quickly become the only game in town.

Many have lamented the rise of ASICs, feeling it departs from the democratic “one computer, one vote” vision laid out by Satoshi Nakamoto in the original Bitcoin design. There is also significant concern that mining is now too centralized, driven by ASICs as well as the rise of mining pools. Because of this, there have been many efforts to design “ASIC-resistant” mining puzzles. One of the earliest alternatives to Bitcoin, Litecoin, chose the memory-hard scrypt instead of SHA-256 in the hope of preventing ASIC mining. Despite this, there are now ASICs for mining Litecoin and their speedup over general-purpose computers may be even greater than that of Bitcoin ASICs. Litecoin’s developers themselves have essentially given up on the principle of ASIC-resistance. Subsequent efforts have included X11, which combines eleven hash functions to attempt to make ASICs difficult to build, but it’s probably only a matter of time before X11 ASICs arise as well. It’s been convincingly argued that ASIC-resistance is probably impossible in the long-term, so we should all accept that ASICs are inevitable in a successful cryptocurrency.

I would like to expand on the argument  here though by positing that ASICs may actually make Bitcoin (and similar cryptocurrencies) more stable by ensuring that miners have a large sunk cost and depend on future mining revenues to recoup it. Even if it were technically possible to design a perfectly ASIC-resistant mining puzzle which ensured that mining was efficient on general-purpose computers, this might be a bad idea if it meant you could obtain a lot of computational capacity and use it in a destructive attack on Bitcoin without significantly devaluing your computational resources’ value.

It’s well-known that an entity controlling the majority of mining capacity can undermine Bitcoin. Famously, they could double-spend by intentionally forking the blockchain, although they could also simply reject all other miner’s blocks to collect 100% of mining rewards and/or censor which Bitcoin transactions are published. There are a variety of other possible attacks without any party controlling an absolute majority, such as “selfish mining” by strategic block withholding or feather-forking. It’s also possible a cartel of miners could try to act as a single majority miner.

To date, none of these attacks has occurred even though surpassed 51% of mining capacity for several weeks in July 2014. The basic theory explaining this failure to attack is that these attacks aren’t the most profitable option available to an entity owning lots of mining capacity. Major attacks would undermine confidence in Bitcoin, tank the exchange rate, and make all the earned Bitcoins much less valuable than what the large miner could have earned by not attacking and simply mining normally. Call this the opportunity cost of attacking argument. Satoshi Nakamoto indeed laid this argument out in the original Bitcoin paper and assured the public they wouldn’t attack for basically this reason.

In economic terminology, the argument is that any large miner has a large expected future earnings from honest behavior and hence a major attack that threatens those earnings will have a high opportunity cost. A key embedded assumption is that there is no other viable use for their computational capacity and that it is a sunk cost.

If we could achieve “perfect” ASIC-resistance, meaning ASICs are no more efficient than equivalently expensive general purpose computers at mining, then a significant portion of this sunk cost would be salvageable and attacking might become a much more attractive option. For example, you could buy a few million computers to mine Bitcoin, perform a one-time attack, and then sell the computers for use in grid computing. Even worse, one might simply rent capacity from a general-purpose cloud-computing service (such as Amazon web services) to perform an attack.

By contrast, if we achieved “perfect” ASIC-friendliness we could ensure Bitcoin mining hardware is a complete sunk cost and maximize the opportunity cost of attacking. There are some limits as the hardware will always have some minimal salvage value simply for raw materials. But we could design a function that was essentially impossible to perform efficiently in software and has no other known purpose. The design of DES actually points to a few tricks for achieving this-we might design SHA-256’ for use in mining by adding some software-killing bitwise permutations and tweaking the constants to ensure it isn’t the same SHA-256 used anywhere else (e.g. for password hashing).

A formal treatment of the “opportunity cost of attacking” argument for Bitcoin remains an open challenge. It’s not proven to hold even in the case of a relatively ASIC-friendly puzzle like SHA-256. But it appears that ASIC-resistance might undermine this key argument for why rational actors shouldn’t attempt many types of attacks on Bitcoin.

This post came from a discussion in Princeton’s new Bitcoin class. Thanks to Akis Kattis in particular for asking questions on this issue as well as to Arvind Narayanan and Ed Felten for reviewing this post.

[1] It’s theoretically possible you could re-purpose some Bitcoin mining ASICs to perform other SHA-256 brute-force tasks such as password cracking. To my knowledge nobody has successfully done this and current mining ASICs could not be made to do so. Perhaps you could redesign a mining ASIC which could also be used for password brute-force, but there are major challenges (the simplest of which is the data bus would need to have much higher bandwidth to transfer all of the password guesses to the ASIC).


  1. I seen you’re want more info about bitcoins from going over this post?
    Feel free to look at my bitcoin faucet rotator to earn some free bitcoins.

  2. For this notion to work, you have to have an expectation of future revenue that would exceed the amount realizable by smash-and-grab. As long as ASICs keep being produced and keep getting cheaper, the revenue expectations of existing operators will decrease (unless there’s massive growth in the rate of transactions and in transaction fees), so looting is intrinsically attractive.

    The real figure of merit (as Peter suggests) is something like the liquidity/detection quotient. As things stand right now, that quotient is pretty low. In other words, it would be difficult to convert the Really Big stash of bitcoins acquired in an attack into conventional currency before an attack was detected, the conversion value crashed, and people started trying to figure out how to manually unwind transactions. (Remember, you have to do your bitcoin –> conventional currency transactions slowly, or the value crashes even without detection.)

    What this means, somewhat paradoxically, is that as soon as bitcoin liquidity goes up enough, and big conversions of bitcoin into other currencies don’t move the market value of bitcoins much, an attack will become more likely.

    • Very good points Paul. Liquidity matters and so do depreciation rates for hardware. Depreciation rates for hardware should start declining-it’s getting closer to cutting-edge and hitting process limits. This paper ( estimated we’re already within an order of magnitude of efficiency limits for Bitcoin miners. So I see depreciation becoming less of a problem.

      I think liquidity is a bit more complex. The attacker doesn’t just need liquidity in the sense that the market will buy a huge number of Bitcoins without the price changin-the attack itself is probably an observable signal that can change the price. If this change happens faster than the attacker can clear their stolen Bitcoins, then the attack is not profitable.

      It would be interesting to write-up an extended discussion of the basic point about sunk costs taking into account these factors.

  3. You can’t make things ASIC resistant, at least not any simple or straightforward algorithm proof of work. There is some optimal hardware for which to run ANY algorithm. Even when talking “general purpose PCs”, the amount of memory, processor speed, number of cores, etc. vary.

    The problem of ASIC resistance is equivalent to making it equally likely an old smartphone, a desktop gaming system, and a new chromebook each have an equal chance of solving a particular problem.

    And this is the wrong question. The correct question is how to create “proof of work” problems that only humans can solve (and it takes years to add one to the pool). If people could get a minimum wage or more just by solving problems, they could do it as a supplement or even the main source of income.

  4. Your argument falls apart if there’s an attack which the attacker can be confident won’t be detected for a while. That’s because the incentive not to attack is that any attack would undermine confidence in Bitcoin and render the investment in the ASICs worthless. But if the attack isn’t detected for a year, the attacker (potentially) has time to take the money and run.

    I don’t know enough about potential Bitcoin attacks to know if it’s possible for a large enough mining pool to conceal an attack. My guess is that blockchain forking is easily detectable, but perhaps there’s a more subtle attack.

    • I agree, though to my knowledge all of the attacks a 51% miner would do are immediately visible. Perhaps censorship or rejecting other miner’s blocks is slightly less detectable, but also much less profitable (and detectable over time). If there were an attack that wasn’t detectable and provided short-term unbounded profits (like double-spending theoretically could) then I agree the opportunity cost argument doesn’t present it.