Ethereum is a Dark Forest

By Dan Robinson and Georgios Konstantopoulos

This story has moved to the Paradigm blog.

I’ve always hoped I would get a chance to work alongside Matt, who has been one of my closest friends for almost twenty years, and who first introduced me to Bitcoin six years ago. But I’m equally thrilled to be joining Fred, who has already had a legendary impact on this small industry, and Charlie, one of the sharpest people I’ve ever met.

‪Another thing that drew me to this opportunity is Paradigm’s long-term perspective, and their commitment to pushing the entire industry forward by investing in basic research. In addition to helping Matt, Fred, and Charlie think about investments, an explicit part of my role will be contributing to research and development on open-source protocols and projects.

I’m looking forward to continuing to work on Bitcoin, Ethereum, Plasma, Interledger, Ivy, and Stellar, as well as getting to explore other areas more deeply, including decentralized finance, proof-of-stake consensus, and zero-knowledge proofs. If you’re working on something interesting, please reach out to me at dan@paradigm.xyz!

‪I have been blessed to have worked with some extraordinary people at Chain and Interstellar over the past 2.5 years‪ and am beyond grateful for the opportunities Adam Ludwin and Jed McCaleb have given me to work on transformative and cutting-edge projects. Adam, and the company he built, changed my life, and taught me countless lessons that I hope to carry forward.

Interstellar is pleased to announce a preview release of Starlight, an implementation of bidirectional payment channels on Stellar. Payment channels allow parties to transact privately, instantly, and securely, while paying zero fees.

Normally, making a payment on a network like Stellar involves publishing details of the payment to all observers, paying a small fee, and waiting for the network to reach consensus and confirm the payment.

A payment channel, on the other hand, uses the network to “lock up” some funds for use by the channel’s participants. They may then pay each other these funds without further involving the network. Such payments are thus private, instant, and free.

The security of the channel is ensured by special information exchanged between the participants with each payment. This information includes signed Stellar transactions that are not published to the network until one party chooses to close the channel. When the channel is closed, these “settlement transactions” send to each party’s Stellar account their respective share of the balance, taking into account the channel’s history of payments back and forth.

Only the final settlement balances are revealed to the network when the channel closes. All other activity in the channel remains private and known only to its participants.

Starlight payment channels are analogous to the Bitcoin payment channels used in the Lightning Network. As we extend the Starlight project to support not only payment channels but also multi-hop payments across those channels, we plan to build in compatibility with other payment-channel networks, such as Lightning and Interledger.

This preview release supports bilateral channels (channels with exactly two participants). It includes the Starlight payment channel software as well as a built-in wallet application. It allows transacting in lumens only (the native asset of the Stellar network). Future versions will support any asset issued on the Stellar network.

This is an early demo release, and you should expect bugs as well as frequent incompatible upgrades. Until we work out the kinks, Starlight connects only to the Stellar testnet, not the mainnet, to eliminate the risk of losing real funds to a software bug. Please do not attempt to use this application with the Stellar mainnet.

You can download the Starlight application, read the source code, and try the demo here. You can learn more about the Starlight payment channel protocol by reading the specification.

Thank you to Jeremy Rubin, Jed McCaleb, Nicolas Barry, David Mazières, Akash Khosla, and others for inventing and developing the designs for payment channels on the Stellar protocol.

Starlight: payment channels on Stellar was originally published in Interstellar on Medium, where people are continuing the conversation by highlighting and responding to this story.

Last Monday, Chain released our open-source smart contract language for Bitcoin, Ivy. Ivy is a higher-level language that can compile to Bitcoin Script, the low-level language used by the Bitcoin protocol to determine whether a transaction is authorized. Ivy makes it easier for humans to read, write, and use Bitcoin smart contracts. But since it is designed to be compatible with Bitcoin today, its features are limited by the current capabilities of Bitcoin’s virtual machine.

What if those limits could be expanded? What if it were possible to get almost all of the safety, simplicity, and efficiency of a small, non-Turing-complete execution language like Bitcoin Script, while gaining much of the flexibility and power of a more expressive programming language?

For this post, we’re going to take a peek at a distant possible future of the Bitcoin protocol, in the form of an exciting paper from Russell O’Connor of Blockstream. O’Connor’s paper proposes a possible replacement for Bitcoin Script, called Simplicity. Like Bitcoin Script, Simplicity is a low-level execution language, intended to be a compilation target for higher-level languages like Ivy. (To learn more about the possible advantages of Simplicity over Bitcoin Script and alternative low-level languages, you can see Blockstream’s announcement, or this review from Philip Wadler.)

O’Connor’s paper lays out everything you need to implement a Simplicity interpreter, but doesn’t provide an executable reference implementation (although he is working to release an SDK in the near future). And following along with the paper can be a little daunting if, like me, you’re not very familiar with the syntax of Coq or sequent calculus.

This post attempts to address both these issues, by demonstrating how to implement core Simplicity using Haskell. Our implementation will use only elementary Haskell — specifically, material from chapters 2, 4, 7, and 11 of Haskell Programming from First Principles. If you’ve ever used Haskell or another functional language like Elm, F#, PureScript, or OCaml, you’ll probably be able to follow along.

You can try out this implementation of Simplicity in your browser, and see the full code, at https://repl.it/@danrobinson/core-simplicity.

In future posts, I might take a look at implementing some of the other features of Simplicity, embedding Simplicity in a less hospitable (but more popular) language, and even building part of a compiler from Ivy to Simplicity.

Goals

We’ll be implementing core Simplicity as a Haskell module. This module exports functions that allows you to write and execute Simplicity expressions as Haskell code, with almost no translation. For example, this Simplicity program from section 2.5 of the paper:

Can be translated into the following Haskell code:

not :: Bit -> Bit
not = comp (pair iden unit) (match (injr unit) (injl unit))

Our implementation will be a shallow embedding. This means every Simplicity combinator and expression will correspond to a Haskell function, and every Simplicity value will correspond to a Haskell value. This allows us to piggyback on Haskell’s AST, as well as its type inference and type checker. If an expression is a valid Haskell expression, we know it is also a valid Simplicity expression.

In this post, we’ll only implement the nine basic combinators of core Simplicity (described in section 2 of O’Connor’s paper). We won’t touch the more sophisticated features of Simplicity, such as sub-expression sharing, merklized abstract syntax trees, and jets.

Types and values

Simplicity has a unit type, 𝟙. (A “unit type” means a type with only one inhabitant.) To represent this type, we will use Haskell’s built-in unit type, () (pronounced “unit”).

In Simplicity, the sole value of the unit type looks like ⟨⟩. In Haskell, the value has the same name as the type itself, ().

Simplicity also has sum types, written A + B, where A and B are other Simplicity types. Each inhabitant of this type is a value of either type A or B, along with a tag indicating whether it is from the left or the right type. For sum types, we will use Haskell’s canonical sum type, Either, which is defined as data Either a b = Left a | Right b.

In Simplicity, the values of this type look like σᴸ(a) (when the contained value is a value of the first type, type A) or σᴿ(b) (when the contained value is a value of the second type, type B). In Haskell, they look like Left a and Right b. For example, the two values that inhabit type Either () () are Left () and Right (). The three inhabitants of type Either (Either () ()) () are Left (Left ()), Left (Right ()), and Right ().

Finally, Simplicity has product types, written A x B. Each inhabitant of such a type is a pair of values — one of type A, and one of type B. We will use Haskell’s built-in tuple type, (a, b).

In Simplicity, values of a product type look like ⟨a, b⟩. In Haskell, they look like (a, b). For example, the four inhabitants of type (Either () (), Either () ()) are (Left (), Left ()), (Left (), Right ()), (Right (), Left ()), and (Right (), Right ()).

Unlike in Haskell, sum and product types cannot be defined recursively. This means that every Simplicity type has a fixed, finite number of possible inhabitants.

Numbers and strings

You’ll notice that Simplicity does not have any built-in support for common primitive types like booleans, integers, or strings. Instead, the Simplicity paper defines such types as combinations of the types described above.

For example, the paper defines a “bit” — a type with two inhabitants, zero and one — as the sum type 𝟙 + 𝟙. In Haskell, this corresponds to the type Either () (), and the two values of it are Left () and Right (). Following the convention used in the paper, we will define these values to mean 0 and 1, respectively.

For our convenience, we can define Bit as a type synonym, along with more descriptive names for its two inhabitants:

type Bit = Either () ()

zero :: Bit
zero = Left ()

one :: Bit
one = Right ()

What if we want to represent not just one bit, but a two-bit “word” — something that can represent any number from 0 to 3? We can take a product type of two bits, (Bit, Bit).

type Word2 = (Bit, Bit)

This type can have 4 possible values: (zero, zero), (zero, one), (one, zero), and (one, one). We can interpret these as the integers 0, 1, 2, and 3, respectively. Alternatively, we could interpret them as bitstrings of length 2.

The Simplicity paper defines larger word sizes as products of two smaller word size types. A 4-bit word is defined as the product of two 2-bit words, an 8-bit word is defined as the product of two 4-bit words, and so on.

type Word4 = (Word2, Word2)
type Word8 = (Word4, Word4)

Expressions and combinators

A Simplicity “expression” is a function from one Simplicity value to another. This is a little unusual — you’re probably accustomed to expressions that can evaluate to single values. (Simplicity also does not have first-class functions — Simplicity expressions are not themselves Simplicity values.)

Simplicity expressions look like this:

pair iden unit

take (take iden)

comp (pair iden unit) (case (injr unit) (injl unit))

Simplicity expressions are composed of combinators. A combinator is a primitive in Simplicity that turns 0 or more expressions into a new expression. There are only nine combinators in core Simplicity.

iden :: a -> a
iden a = a

The iden combinator is not parameterized with any other expressions — iden by itself is a valid Simplicity expression. The expression iden is a function that takes a Simplicity value and returns the same value.

unit :: a -> ()
unit _ = ()

The unit combinator, similarly, does not take any other expressions. unit is a function that ignores its input and returns a single value of type unit, ().

comp :: (a -> b) -> (b -> c) -> a -> c
comp s t a = t (s a)

The comp combinator takes two expressions, s and t. Remember, each of these expressions is itself a function from one Simplicity value to another. When partially applied to s and t, comp returns an new expression that takes some value a, applies the s expression to it, and then applies the t expression to that result.

Note that the last argument to comp, a, is a Simplicity value. In contrast, all of the previous arguments are Simplicity expressions (i.e., Haskell functions). Because of Haskell’s automatic currying, you can also think of comp as a function that takes two expressions s and t, and returns a new expression (i.e., a new Haskell function from one value to another).

                                    [         expression          ]
combinator   expression  expression     input value   output value
             (* -> *)    (* -> *)    -> *          -> * 
comp ::      (a -> b) -> (b -> c)    -> a          -> c
comp         s           t              a          -> t (s a)

This is a useful perspective, and arguably the “correct” one, not only because of the different nature of the arguments but also because of the difference in when these arguments are passed. The expressions s and t are provided at the time the Simplicity program is written (i.e., by the programmer or compiler), and the value a is provided at runtime, when the program is run.

injl :: (a -> b) -> a -> Either b c
injl t a = Left (t a)

injr :: (a -> c) -> a -> Either b c
injr t a = Right (t a)

The injl and injr combinators each take one expression, t. When applied to a value, they first apply the expression t, and then inject the result into a sum type by adding a Left or Right tag, respectively.

match :: ((a, c) -> d) -> ((b, c) -> d) -> (Either a b, c) -> d
match s t (Left a, c) = s (a, c)
match s t (Right b, c) = t (b, c)

The match combinator (renamed from Simplicity’s case because case is a reserved word in Haskell) takes two expressions, s and t. When applied to a value, which must be a product (ab, c), it pattern-matches on ab, and applies either s or t to the contained value (along with the extra state c) based on whether the tag is a `Left` or `Right`, respectively.

pair :: (a -> b) -> (a -> c) -> a -> (b, c)
pair s t a = (s a, t a)

The pair combinator takes two expressions, s and t. When applied to a value, it creates a pair whose first value is the result of applying s to a, and whose second value is the result of applying t to a.

take :: (a -> c) -> (a, b) -> c
take f (a, _) = f a

drop :: (b -> c) -> (a, b) -> c
drop f (_, b) = f b

The take and drop combinators each take one expression, f. When applied to a value — which must be a product (a, b) — they apply the expression f to the first or second value, respectively, and throw the other value away.

Example Simplicity programs

Now we can use these combinators to define expressions that represent arbitrary functions from inputs to outputs.

The following examples are taken almost verbatim from the Simplicity paper (just translating the type names and type annotation syntax, and changing case to match).

not :: Bit -> Bit
not = comp (pair iden unit) (match (injr unit) (injl unit))

This function takes one bit (zero or one, i.e., Left () or Right ()) and converts it into the opposite bit.

How does this work? Suppose we apply this expression to the value Left (). We can use equational reasoning to gradually simplify this expression, one combinator at a time:

comp (pair iden unit) (match (injr unit) (injl unit)) (Left ())
-- comp s t a = t (s a)
match (injr unit) (injl unit) ((pair iden unit) (Left ()))
-- pair s t a = (s a, t a)
match (injr unit) (injl unit) (iden (Left ()), unit (Left ()))
-- iden a = a
match (injr unit) (injl unit) (Left (), unit (Left ()))
-- match s t (Left a, c) = s (a, c)
injr unit ((), unit (Left ()))
-- injr s a = Right (s a)
Right (unit ((), unit (Left ())))
-- unit _ = ()
Right ()

To try this out, you can use the online REPL at https://repl.it/@danrobinson/core-simplicity, or download the code from there and try it yourself in ghci:

> not zero
=> Right ()
> not zero == one
=> True
> not one == zero
=> True

This next function takes two one-bit numbers, adds them, and returns an overflow bit and a result:

halfAdder :: (Bit, Bit) -> (Bit, Bit)
halfAdder = match (drop (pair (injl unit) iden)) (drop (pair iden not))

You can use this half-adder to build a full-adder, which takes two one-bit numbers and an overflow bit and returns a new overflow bit as a result:

fullAdder1 :: ((Bit, Bit), Bit) -> (Bit, Bit)
fullAdder1 = comp (pair (take halfAdder) (drop iden))
            (comp (pair (take (take iden))
            (comp (pair (take (drop iden)) (drop iden))
              halfAdder))
            (pair (match (drop (take iden)) (injr unit))
              (drop (drop iden))))

You can try it out too:

> fullAdder1 ((one, one), zero)
=> (Right (),Left ())
> fullAdder1 ((zero, zero), one)
=> (Left (),Right ())

These last two functions implement adders for 2-bit words and 4-bit words. (The Simplicity paper defines these recursively, but doing so in Haskell would require some type-level magic that’s beyond the scope of this post.)

fullAdder2 :: ((Word2, Word2), Bit) -> (Bit, Word2)
fullAdder2 = comp (pair (take (pair (take (take iden))
                                   (drop (take iden))))
            (comp (pair (take (pair (take (drop iden))
                                    (drop (drop iden))))
                        (drop iden))
                   fullAdder1))
            (comp (pair (drop (drop iden))
                  (comp (pair (take iden)
                              (drop (take iden)))
                        fullAdder1))
            (pair (drop (take iden))
                  (pair (drop (drop iden)) (take iden))))

fullAdder4 :: ((Word4, Word4), Bit) -> (Bit, Word4)
fullAdder4 = comp (pair (take (pair (take (take iden))
                                    (drop (take iden))))
            (comp (pair (take (pair (take (drop iden))
                                    (drop (drop iden))))
                        (drop iden))
                    fullAdder2))
            (comp (pair (drop (drop iden))
                  (comp (pair (take iden)
                              (drop (take iden)))
                        fullAdder2))
            (pair (drop (take iden))
                  (pair (drop (drop iden)) (take iden))))

Conclusion

Hopefully this post has made it easier to understand and try out core Simplicity. I also hope it demonstrated some of the power and flexibility that Haskell provides when working with domain-specific languages.

Thanks to Russell O’Connor, Boyma Fahnbulleh, Bob Glickstein, and Keith Rarick for reviewing a draft of this post.

Would such a divergence between hashrate and price be sustainable? I’m sure that some miners, traders, and exchanges have analyzed this exhaustively, but such analysis doesn’t seem to have filtered out to the broader community beyond the conclusion that “hashrate will ultimately follow price.” This post tries to justify that conclusion, arguing that supporting a less-valuable fork would likely be unsustainably expensive for miners, even in the short run. My estimate is that if the price predictions hold, subsidizing the B2X chain rather than calling off the fork could cost miners as much as $100 million in the first 10 days.

We’ll just be looking at the 10 days following the fork — or, more precisely, the period before either chain adjusts its difficulty — with a focus on what would happen if the futures prices and miner signaling both turn out to be approximately accurate, and B2X starts out with 80% of BTC’s mining power but only 20% of its value. My primary goal will be to estimate the short-term opportunity cost miners would be sacrificing if they mine the B2X chain in that scenario.

I’m not considering the longer-term incentives that miners might have for choosing to sacrifice this much to support the chain. I also do not consider any more sophisticated strategies that a mining cartel might undertake collectively, such as launching a 51% attack—or selfish mining attack—against one or both chains, or dedicating mining power to other coins such as Bitcoin Cash. Such a development is certainly possible, but will have to be covered in a future post. Finally, I’m not making any estimates of miner expenses, which are hard to determine, and are essentially irrelevant to the opportunity cost of mining one chain rather than another.

Estimating revenue

First, let’s estimate how much an individual miner would earn by mining the B2X chain versus the B1X chain until the first difficulty adjustment.

We can estimate a given miner’s revenue over a period of time using the following formula:

Rate of block generation ⋅ Time ⋅ (Block reward+ Fees) ⋅ Price

Let’s examine each of these components in turn.

Rate of block generation

The first component in the formula is the rate at which a given miner generates blocks on the chain on which they are mining.

This depends on two factors, the difficulty—a measure of how hard it is to generate a new block—and the miner’s own hashrate. Difficulty is ultimately based on total mining power of the network—as the total hashrate dedicated to mining Bitcoin grows or shrinks, the protocol adjusts the difficulty (or more precisely, the target that miners must hit) to keep the rate of new block creation close to once every 10 minutes. But difficulty is only adjusted every 2016 blocks (every two weeks, when blocks are being created at their normal rate).

It turns out that before the difficulty adjusts, the rate at which a particular miner generates blocks is independent of the actions of other miners. This is because the rate at which you generate blocks is a function of only two things: the block difficulty, and your own hashes per second. If other miners abandon the chain you are mining, then the rate at which the whole chain generates new blocks will slow down, but your rate of generating new blocks will not change until the difficulty adjusts.

This means that a miner who is earning 1 BTC per hour pre-fork in block rewards would, immediately after the fork, have the choice between earning 1 B1X per hour and 1 B2X per hour, no matter what other miners are doing.

(One caveat is that a slower blockchain may have a slightly lower orphan block rate, but orphan blocks are sufficiently rare under ordinary circumstances that this will probably not be material.)

So, an individual miner’s rate of block generation does not depend on which fork they mine or how many other miners are mining that chain (until the difficulty adjustment). However, each chain will generate blocks slower or faster, based on the total hashrate committed to that block. With 80% hashrate, the B2X chain would, on average, mine one block every 12.5 minutes. With 20% hashrate, the B1X chain would, on average, mine one block every 50 minutes.

Time

How long will it take until the difficulty adjustment?

The fork is scheduled to occur at block 494,784. For both the B1X and B2X chains, difficulty is scheduled to adjust 1152 blocks later, at block 495,936. With mining power split between two chains, it will likely take significantly longer than normal, particularly for the chain with minority hashrate.

The amount of time before the first difficulty adjustment will probably be somewhere between 8 days (if all miners join one chain, which therefore generates blocks every 10 minutes) and 16 days (if mining power is evenly split between the two chains, which therefore generate blocks every 20 minutes). It could conceivably be longer, if some BTC miners stop mining altogether after the fork, or temporarily defect to another coin such as Bitcoin Cash.

If about 80% of pre-fork BTC miners start mining B2X after the fork, the B2X fork will be about 4 times faster, and will therefore adjust its difficulty much sooner. At a rate of one block every 50 minutes, the difficulty adjustment for B1X would happen only 40 days after the fork. At a rate of one block every 12.5 minutes, the difficulty adjustment for B2X would happen approximately 10 days after the fork, so let’s consider that to be our cutoff.

Block reward

One component of coins earned per block is the block reward, which amounts to 12.5 coins per block. This will be the same for both chains — the B1X chain will give miners 12.5 B1X per block, and the B2X chain will give miners 12.5 B2X per block.

Fees

The other component of coins earned per block is transaction fees. Total transaction fees per block have mostly ranged between 1 and 4 BTC over the past six months, averaging around 2 BTC per block. Transaction fees are difficult to estimate, but since they are the less significant component of miner income, it’s not essential that we get this exactly right.

Transaction fee revenue depends, of course, on the demand for transacting on each chain. There may be more desire to transact on the faster, more secure chain (although, since B1X and B2X will be different assets, its not clear that transactions on the two chains will be treated as substitutes), and some businesses will likely follow through on their stated intention to favor the B2X chain.

On the other hand, slower blocks will mean more transactions per block, and thus higher transaction fees per block. If the B1X network only mines a block every 50 minutes but the B2X network mines a block every 12.5 minutes, then, all other things equal—and in the absence of a block size limit—transaction fees per block would be about 4 times higher for the B1X chain than for the B2X chain.

Of course, the block size is not unlimited, and it’s likely that if B1X blocks are mined only every 50 minutes, most blocks would be full, which complicates the analysis. Complicating it further is the fact that the situation is not symmetrical between B1X and B2X, because B2X increases the block size by a factor of 2. But the effect of block size on total transaction fees per block is unclear, since smaller blocks tend to have higher fees per transaction. After the effective block size increase imposed by SegWit activation in late August, transaction fees per block actually went down (although there were likely some confounding factors).

Given all these counteracting factors, predicting transaction fee revenue per chain precisely is a difficult task. If B1X is significantly slower, I would predict that the latter effect would dominate and transaction fees per block on B1X would be higher, but let’s be generous and assume that transaction fees are approximately equal, and that the existing transaction fees per block for BTC are evenly split between B1X and B2X. (Additionally, if we avoid making too much use of assumptions about the total mining power on each chain—which, recall, did not affect the rate at which each miner generate blocks—our analysis will be more generally applicable to other scenarios.)

So let’s imagine that transaction fees are the same for each chain: around 1 coin per block.

Price

By the assumption we made in the introduction, B1X maintains 80% of BTC’s current price, and B2X maintains 20%. (This is actually more conservative than the futures markets, which have tended to put B1X’s share at closer to 85%.) So based on today’s price of $7200, the price of B1X would be about $5760, and the price of B2X would be about $1440.

Some might question whether it’s plausible for B1X to maintain its price for 10 days even if it has only 20% of mining power. The futures markets certainly seem to indicate an expectation that it will. Rather than go into an exhaustive analysis of this question, which is somewhat outside the scope of this post, I’ll just note that there doesn’t seem to be any direct mechanism by which a temporary drop in hashrate would drive an immediate drop in price, whereas a temporary drop in price has a clear effect on miners’ immediate incentives.

Estimating opportunity cost

Let’s now try to estimate the opportunity cost of mining the B2X chain rather than the B1X chain, assuming our assumptions about mining power and price hold.

Our main conclusion above is that for the first ten days, a miner will earn approximately the same number of coins whether they choose to mine B1X or B2X, regardless of how many other miners choose to mine each coin. This is very convenient for our analysis.

First, let’s examine the opportunity cost for an individual, “marginal” miner, who needs to decide which chain to mine, but is too small to have an impact on the speed of the chain. The calculation is simple—since the B1X coin is worth four times as much, the miner’s revenue will be four times higher if they mine B1X as if they mine B2X.

To put it in concrete terms, let’s imagine a miner who currently mines $1,000 of BTC a day. In the 10 days following the fork, thry will have to choose between mining a total of $8,000 worth of B1X, or $2,000 worth of B2X.

It seems clear that if the above assumptions hold, then until the difficulty adjustment, it will probably be individually rational to mine the chain of the most valuable coin, regardless of what other miners do. Note that this is true even if a miner disagrees with the market on the future value of the currencies— if a miner would rather hold B2X, they could earn it four times faster by mining B1X and trading it for B2X.

Does it change our analysis if we consider the short-term interests of the entire 80% of miners currently signaling support for mining B2X, as a group? After all, there is evidence that miners sometimes act more like a cartel than like a collection of individual independent actors. What is the opportunity cost for those miners, compared to abandoning B2X and continuing to mine the B1X chain?

It turns out that considering this entire group as a single actor only strengthens the conclusion that abandoning the less-valuable chain would be the rational move.

If these 80% of miners choose to mine B2X, then in the ten days following the fork, they will mine a total of 1152 blocks. If, as we estimated above, each of these blocks pays 12.5 B2X in block rewards and 1 B2X in transaction fees, for a total of 13.5 B2X, then their total revenue over those 10 days would be 15,552 B2X. If the price of B2X is $1440, that’s a total of $22 million.

In contrast, if they choose to mine B1X, those miners would still mine a total of 1152 blocks in 10 days, but would be paid in B1X. Even under the above assumptions about transaction fees and prices for B1X, they would expect to earn 15,552 B1X for a total of $89 million—making $67 million more by mining B1X rather than B2X.

But in fact, since this would effectively be equivalent to abandoning the B2X fork, the most likely outcome might be that B1X would maintain the price and transaction quantity of BTC (although, since the recent run-up in price may have anticipated some fork, it’s possible that the price would pull back a little). If those 80% of miners call off the fork, but the BTC price remains stable, and total transaction fees per block remain around 2 BTC per block, then their expected revenue would be 14.5 * $7200 * 1152 = $120 million, making the opportunity cost around $98 million for those 10 days.

Conclusion

Supporting an unpopular fork by mining it instead of a more valuable chain turns out to be extraordinarily expensive at Bitcoin’s current price. This situation is likely to be unsustainable—individual miners would have a strong incentive to defect, and cartels would need to sacrifice considerable returns to maintain a higher hashrate.

Of course, a cartel might be willing to sacrifice substantial short-term gains now if it guaranteed higher revenues in the future. In a follow-up post, I’ll examine what would happen after the B2X difficulty adjustment 10 days after the fork—which would likely make mining B2X slightly less unprofitable — and the B1X difficulty adjustment 30 days after that—which would likely make mining B1X dramatically more profitable. I may also take a closer look at other strategies that powerful miners might consider, such as 51% attacks or selfish mining attacks. [UPDATE, November 8: Turns out the follow-up post would be moot, because the 2x fork has been abandoned by its primary supporters.]