Merge pull request #21 from Nagalim/master

Protocol Attacks & Misc

text/0011-pos-inflation-adjustment/0011-pos-inflation-adjustment.md

@@ -53,15 +53,11 @@ nSubsidy can be modified directly using nInflationAdjustment.
 Creating and validating blocks will require a search through a substantial number of most recent block (~50,000) PoS rewards which increases the load on both minting and nonminting nodes.
 A node with recent blocks still in memory, such as during a fresh download of the blockchain, may be able to avoid the increased load.
 
-*Exacerbated Protocol Attacks*  
-N@S and Stake Grind attacks are currently considered impractical because the reward to relative cost is very small, being limited only to a small amount of compounding interest.
-By increasing the PoS reward, we increase the risk associated with such attacks.
-
 *Timing Attacks*  
 Minting before finding a valid PoS block is not possible, however a minter may always withhold blocks in an attempt to attain the best reward.
 There are two variables that contribute to `nInflationAdjustment` that can be timed.  
 The first, `nMoneySupply`, is so insensitive to block-by-block changes that we will ignore its affects as a concern.
-This constitutes a generic statement that Inflation Adjustments with a first order dependence on nMoneySupply alone are not susceptible to timing attacks.
+This constitutes a generic statement that any `nInflationAdjustment` with a first order dependence on `nMoneySupply` alone is not susceptible to timing attacks.
 The second variable that can be timed is `nAnnualPoSRewards`, where we will focus for the remainder of this drawback.
 
 To instruct, we shall observe three extreme cases:  
@@ -74,8 +70,9 @@ In this situation, `nInflationAdjustment = 1/(fraction of minters participating)
 The value of `nInflationAdjustment` will fluctuate regularly during this stage.
 
 3. Suddenly, every single minter begins minting consistently and continuously for the rest of time.
-In this situation, `nInflationAdjustment` will quickly sink to 1 and remain there.
-The value of `nInflationAdjustment` will fluctuate minimally, both above and below 1, due to statistical aberration and random coin distribution.
+In this situation, `nInflationAdjustment` will quickly sink to below 1 and remain there.
+The equilibrium value will be driven to approximately 0.99 due to compounding interest.
+The value of `nInflationAdjustment` will fluctuate minimally above and below the equilibrium value due to statistical aberration and random coin distribution.
 
 When making a Timing Attack, the attacker will seek to move their block rewards closer to case 1.
 When choosing to withhold PoS blocks, the attacker is ultimately betting that `nAnnualPoSRewards` will decrease with time.
@@ -86,10 +83,27 @@ Therefore, it is nearly always in the Timing Attacker's best interest to release
 *Timestamp Attack*  
 A minter has 2 hours to place a block on the chain.
 A minter can also somewhat reliably predict the window for minting an output as much 30 days in advance.
-If the minter finds two blocks within the shorter time window, the later block will always have an equal or higher `nAnnualPosRewards`.
+If the minter finds two blocks within the shorter time window, the later block will always have an equal or lower `nAnnualPosRewards`.
 If the minter finds two blocks within the longer time window, they can choose to withhold their first block as a Timing Attack with a high probability of success.
 Both of these forms encourage minters to use later timestamps, which is a mild but undesireable side effect.
 
+*Exacerbated Protocol Attacks*  
+N@S and Stake Grind attacks are currently considered impractical because the reward to relative cost is very small, being limited only to a small amount of compounding interest.
+By increasing the PoS reward, we increase the risk associated with such attacks. It is also possible that an attacker might manipulate `nInflationAdjustment` via a N@S and/or Stake Grind attack.
+
+As a case study, we can imagine a world where an attacker has near-infinite computational resources and perfect knowledge over the network.
+We will also assume that they have ~20% of the minting power, and that 50% of the network is minting (such that the attacker posesses 10% of the entire network).
+We will then assume that the attacker uses half of their coins to create millions of small stake outputs, and the other half of their coins goes into a single output.
+The attacker will then mint a long chain in secret using the small stakes and cap it off with the large stake transaction before broadcasting it.
+We want to isolate the effects of this RFC on the attacker reward for forcing a large reorg of this nature, so we will ignore possibilities such as Double Spend attacks which are unaffected by this RFC.
+Again, we look to the effects on `nAnnualPoSRewards`, which is reduced for every block reorged because the attacker is taking everyone else's PoS rewards.
+However, we must realize that this effect is averaged over the entire year, so if we assume that the PoS rewards are evenly distributed throughout the year aside from the attacker's blocks, then the total effect on the attacker's `nInflationAdjustment` will only be approximately 1/52560 per block of stake grind.
+To have a substantial effect, this would mean that the attacker would have to find thousands of blocks in private and still beat the main chain's difficulty, which is unlikely.
+In addition, the best result they can hope for is that they go from 2% per year to `nAdjustmentMaximum`, and they will likely lose a considerable chunk of compounding interest doing so.
+
+As such, we should assume that the main influence RFC-0011 has on exacerbating protocol attacks comes strictly from the increased block reward, rather than direct manipulation over `nInflationAdjustment`.
+Therefore, to approximate the additional risk introduced to the protocol via N@S or stake grind attacks, one should simply assume that RFC-0011 will result in the protocol continuously operating at `nAdjustmentMaximum`.
+
 ## Alternatives
 
 *Year by Block*