Topic: On The Longest Chain Rule and Programmed Self-Destruction of Crypto Currencies (Read 17957 times)

   3. Sharing revenue proportationally with the fork(s) of lower cumulative
      difficulty entirely defeats selfish mining (positive relative revenue) for
      any α. All blocks in the merged forks receive their full block reward
      adjusted by relative difficulty.

         r_others = p_0(1-α) + p_1(1-α) + p_2(1-α) + p[k>2](1-α), cases (e), (f), (g), and (h)
         r_pool = p_1(1-α)/2 + p_2(1-α)2 + p[k>2](1-α)/2, cases (f), (g), and (h)

         r_others = p_1(1-α)(1/α + 1 + α/(1-α) + (α-1)/(2α-1) - 1 - α/(1-α))
         r_pool = p_1(1-α)(1/2 + 2α/(1-α) + (α-1)/(4α-2) - 1/2 - α/(2-2α))

         R_pool = (3α/(2-2α) + (α-1)/(4α-2))/(1/α  + 3α/(2-2α) + 3(α-1)/(4α-2))

      Plot the following at wolframalpha.com.

         (3α/(2-2α) + (α-1)/(4α-2))/(1/α  + 3α/(2-2α) + 3(α-1)/(4α-2)),  α, 0 < α < 0.5

      However, merging forks of lower cumulative difficulty would remove the
      economic incentive to propagate forks as fast as possible; and issuing a
      double-spend would be trivial. The solution is to only merge forks of
      lower cumulative difficulty when they are known by the majority before
      receiving a fork of higher culmulative difficulty. Thus an attacker or
      network hiccup that creates a hidden higher culmulative difficulty fork
      has an incentive to propagate it before that fork falls behind the
      majority. A node assumes it is part of the majority if it is participating
      non-selfishly; it will attempt to merge any lower culmulative difficulty
      forks it was aware of upon receiving a higher culmulative difficulty fork.
      If it is not part of the majority, then its attempt will not be accepted.
      If there are double-spends at stake, each node will continue to try for
      the longest fork miners wish to be able to merge, i.e. longer forks with
      double-spends won't be merged so the market will decide the value of the
      two forks. If there are no double-spends at stake then to defeat selfish
      mining, each node will continue to try during the duration of the longest
      fork probable for an attacker α < 0.5[6]. If a node selfishly forsakes its
      obligation and joins the attacker, that node attacks the value of the
      block rewards it earned.

      Also, forfeiting double-spends defeats any incentive to temporarily rent
      greater than 50% of the network hashrate because the persistent honest
      miners will forfeit the double-spends from the attacker’s fork upon it
      relinquishing control. Compared to Bitcoin, there is no increased
      incentive to double-spend, because miners will not place into any block a
      double-spend they’ve already seen; double-spends can only appear in forks.
      In Bitcoin one fork wins so one transaction from each of the double-spend
      is forfeited so the honest recipient loses when the attacker’s fork wins.
      In this new algorithm both of the transactions from each double-spend are
      forfeited, so both the honest recipient and the attacker lose.

      Defeating short-term rented hashrate attacks in conjunction with only
      accepting inputs to a transaction which are as old as the longest duration
      fork that will be merged, proves the probability of a double-spend[6] to
      be determined solely by the number of block confirmations no matter how
      fast the block period is.

      Instead of monolithically choosing a winning fork, forfeiting double-
      spends deletes selective downstream transactions. Thus fully opaque block
      chains such as Zerocash, are thought to be incompatible because they not
      only obscure which transaction consumed its inputs but also hide any coin
      identifier that could correlate spends on separate forks. Cryptonote’s
      one-time ring signatures are more flexible because mixes could choose to
      mix only with sufficiently aged transaction outputs.

      Each block of the Proof Chain contains a tree of block hashes, which are
      the forks that were merged and a branch in a subsequent block may continue
      a branch in a prior block. The restricted merging rule, double-spend
      forfeiture and proof trees avoid the risks of Ethereum’s proposed
      approximation[5]. Miners have to maintain transaction history for the
      longest fork they wish to merge. And downstream consumers of inputs must
      wait for the longest fork they anticipate[6].


   [5] https://blog.ethereum.org/2014/07/11/toward-a-12-second-block-time/
       Now, we can’t reward all stales always and forever; that would be a
       bookkeeping nightmare (the algorithm would need to check very diligently
       that a newly included uncle had never been included before, so we would
       need an “uncle tree” in each block alongside the transaction tree and
       state tree) and more importantly it would make double-spends cost-free...
       Specifically, when only the main chain gets rewarded there is an
       unambiguous argument...Additionally, there is a selfish-mining-esque
       attack against single-level...The presence of one non-standard strategy
       strongly suggests the existence of other, and more exploitative,
       non-standard strategies...True. We solved the selfish mining bugs of
       traditional mining and 1-level GHOST, but this may end up introducing
       some new subtlety; I hinted at a couple potential trouble sources in the
       post.
   [6] Meni Rosenfeld. Analysis of hashrate-based double-spending.
       Section 5 Graphs and analysis.
       http://arxiv.org/pdf/1402.2009v1.pdf#page=10