[Note: Below is a guest post from Ernie Teo, a post-doctorate researcher at SKBI (where I am currently a visiting research fellow). It is referenced in a new paper covering the distorted incentives for securing public blockchains.]
Integrating, Mining and Attacking: Analyzing the Colored Coin “Game”
By Ernie G. S. Teo, Sim Kee Boon Institute for Financial Economics,
Singapore Management University
The research in this post came about when Tim Swanson invited me to look at colored coin providers and their incentives from a game theory perspective. The results are based on a number of phone conversations with Tim; I would like to take the opportunity to thank Tim for his insights on the matter. For an introduction to what colored coins are, refer to Chapter 3 in Great Chain of Numbers.
The initial question Tim wanted to know was if colored coins can be identified will miners charge excessively high fees to include these transactions. The led to a discussion of the possibilities of the colored coin issuer becoming a miner; and of an attack on the network to take control of the colored assets.
The problem proved to be very interesting as there could be many implications on the success of the system given the potential costs and benefits. Entities or players within the “game” could strategically choose to sabotage themselves if the incentives were right. In this post, I will attempt to explain this using a “sequential game” format. I will explain the various stages where choices can be made and the players involved in each stage. This will be followed by an analysis of the various outcomes and the strategic choices of each party given the incentives involved.
Before we start, I would like to disclaim that the model that follows is a simplified version of the problem and helps us to think about the potential issues that could arise. They are based on various assumptions and in no way should the results be taken at face value.
Stage 1: Before the colored coin issuer (CCI) starts operations, we assume that they will consider if they will choose to become a miner (Assuming that they can include their own transactions into blocks if no one else would). The decision maker (or player) here is the CCI, the choices available are to integrate or to not integrate.
Stage 2a: When the CCI starts issuing colored coins, it would have to decide on the fees it would pay for the transaction. We assume that the CCI is a rational entity and will choose the optimal fees. However as there are two possibilities in stage 1, there will be 2 possible fees quoted; one for a CCI whom is also a miner (integrated) and another for a CCI whom is not a miner (non-integrated). The decision maker here is the CCI and the choice is the fee quoted.
Stage 2b: This is immediately followed by the miners deciding to include the transaction in the block or not. For simplicity’s sake, we assume that there is only one miner in this game (this can be the CCI). The decision maker here is the miner and the choice is to mine the transaction or not.
If the decision in Stage 2b is not to mine, the game ends (End 1).
Stage 3: We next assume that the miner can choose to fraudulently attack the system and transfers the colored coin to itself. The decision maker here is still the miner and the choice is to attack or not.
This gives us 2 alternative endings (End 2 and End 3). The game can be described by Figure 1.
If we consider the game, there are only 2 decision makers or players: The CCI and the miner. Next, we consider what are the possible outcomes or payoffs for each possible ending described above. This is described in Figure 2 below, there are actually 6 possibilities as there are 2 types of CCIs, integrated and non-integrated. When there is integration, there is really only one player.
Having setup the game and determined the payoffs, we analyze the possibilities of each outcome. This is subject to the comparative magnitude of each payoff. Let’s start with the non-integrated outcomes, there are 3 possibilities:
- Not Integrated. Mined. Attacked.
- Not Integrated. Mined. Not Attacked.
- Not Integrated. Not Mined.
An attack happens if M3>M2 (this will happen if the net benefit of the attack is positive).
If M3>M2, the transaction will be mined if M3>M1. This is because the miner expects the attack to take place, the miner will thus only mine the transaction if it the payoff from mining and attacking is better than not mining. Since we assumed that M1=0, M3 will be always larger than M1. Thus When M3>M2, mining always takes place and an attack happens.
If M2>M3, the attack will not happen (this would indicate that the net benefits of the attack is negative). The transaction will be mined if M2>M1 or if the transaction fees are positive.
The transaction will not be mined if M1≥M2. Since M2 (the transaction fee) has to be at least zero, if M2=0, the transaction will not be mined.
To summarize, there are 3 scenarios:
- M3>M2≥M1: The transaction is mined and an attack takes place. The CCI gets CC3NI.
- M2>M3 and M2>M1: The transaction is mined and an attack will not take place. Note that the inequality between M1 and M3 does not matter for this outcome. The CCI gets CC2NI.
- M1≥M2>M3: The transaction is not mined. The CCI gets CC1NI.
In stage 1, the CCI is making the decision to integrate. To analyze this, we need to compare the non-integrated outcomes with the integrated ones. We thus have to look at the integrated outcomes first before we discuss stage 1. The outcomes are:
- Mined. Attacked.
- Mined. Not Attacked.
- Not Mined.
An attack happens if CC3I>CC2I. (This again will happen if the net benefit of the attack is positive).
If CC3I>CC2I, mining will occur if CC3I>CC1I. Similar to the non-integrated case, CC3I is always larger than CC1I . In fact this case is stronger as CC1I is at most zero and is likely to be negative as it is a cost. Thus if the CCI is willing to launch an attack against itself, it will definitely mine the transaction.
If CC2I>CC3I, no attack happens. For mining to occur, CC2I≥CC1I (the CCI will prefer to mine if they are indifferent). CC2I will always be larger than CC1I unless mining fees are zero (in which case it is equal), mining will always occur if CC2I>CC3I.
For mining to not occur, CC1I>CC2I or CC1I>CC3I needs to hold. To summarize, there are 3 scenarios:
- CC3I>CC2I and CC3I>CC1I: The transaction will be mined and an attack occurs. CC3I is the final payoff.
- CC2I>CC3I and CC2I>CC1I: The transaction is mined and no attack happens. CC2I is the final payoff.
- CC1I>CC3I (we had determined that CC1I>CC2I could not be possible): No mining occurs. CC1I is the final payoff.
Note that we have determined that mining will always occur if the CCI chooses to integrate. Thus there are only 2 relevant scenarios instead of the 3 found in the non-integrated case. The main assumption is that the CCI miner will be able to get its transaction included on the blockchain; this could be either because it is the only miner or it has invested in sufficient computing resources to ensure it.
There are a total of 9 combinations of events detailed in Figure 3. Figure 3 also shows the conditions required for integration to occur under each scenario.
Referring back to figure 2, we can make the following assumptions:
CC1NI is always larger than CC1I
CC2NI is always larger than CC2I
CC2NI is always larger than CC1I
Thus the 3 inequalities highlighted in red in Figure 4 are never possible, no integration will occur in scenario B+E, B+F and C+F.
In the other 6 scenarios, integration could occur given the right conditions. We can make some predictions on what is likely to occur.
- In all scenarios with event A (A+D, A+E and A+F) where the non-integrated miner attacks, it is likely that the CCI prefers to integrate.
- In scenario B+D, there are two possibilities. If the cost of attack is large, the CCI will not integrate. Otherwise, it will integrate and reap the benefits of launching an attack on itself.
- When event C occurs and no integration takes place, the transaction will not be mined and the CCI gets nothing. Integration will thus occur as long as the cost of integration is small enough. This will be relevant for scenario C+D and C+E as we has ruled out C+F earlier.
One may ask if the CCI would want to attack itself. Well, if the benefit of attacking is large, a colored coin issuer may want to attack the network to derive a onetime benefit even though the company will never be trusted afterwards. However, this is unlikely as the cost of integration has to be extremely large for the CCI to be able to successfully attack the network.
Finally to answer our initial question, let us consider the issue of whether a non-integrated miner (in the event that a colored coin transaction can be identified) will force the CCI to quote high fees in order to get the transaction included. This is only relevant in the scenarios where the CCI initially chooses not to integrate. However, if colored transactions can be identified, miners can choose not to include these transactions unless the transaction fees are high enough. The fee can only be so high that it does not force the CCI to choose integration instead. In general, we can say that this fee cannot be higher than the cost of integration (this would refer to the per transaction cost of integration on average).
Based on this “game”, will colored coins be able to exist on a network such as Bitcoin? If colored transactions can be identified, there could be 2 issues. 1. The colored assets are so valuable that the non-integrated miner would want to attack the system, 2. The fees do not incentivized non-integrated miners to include the transactions. To overcome these issues the CCI could chose to integrate (or become a miner with sufficient computing power to be able to ensure that its transactions gets recorded). However, if the cost of doing so is too high to be justifiable, the CCI is better off not operating at all.
Share the post "Integrating, Mining and Attacking: Analyzing the Colored Coin “Game”"
Interesting. But I stalled at the sentence “An attack happens if M3>M2” because neither M1 nor M2 nor M3 have been explained in the text 🙂
Pingback: No, "Blockchain" is not a solution looking for a problem – Bits on Blocks