Hello Shelby,
The maximum defense against any attack in a stake based system can only be 100% stake (unless the system is a hybrid system). For a typical long range attack scenario which is likely to go back several months to fork off, the honest chain will be able to accumulated near 100% signatory stake. Why? (Section 2.3.26)
It’s arduous to read that section of your whitepaper because you jump directly into detailed specification without providing an explanation of the essence of what you’re accomplishing with the details. Also I find your explanation of that section to be lacking clarity (same as my complaint earlier when I via @Traxo re-summarized the Schelling point essence of your system in one paragraph). The part of about unshared and shared and which blocks or epochs get counted and what is the point of 1(a)(b)(c)(d). Seems incomplete or incoherent to me. Maybe it is just me having difficulty grokking that.
I am going to take another attempt at rewriting this section.
I wrote the following description for the fork selection. I'd update the paper shortly.
Regards,
Shunsai
Fork Selection and Defense Against AttacksNetwork participants may receive different forks from other participants and have to choose the preferred fork to build upon. This can happen when a party joins the network for the first time or after a hiatus. It can also happen when an adversary offers an attack fork to the network. An honest party, in any of these situations, must determine which one of the forks is the honest fork.
The protocol makes the following assumptions about the characteristics of the honest fork vs. attack forks and uses these treatments to give preference to the honest fork:
1. The honest fork is more likely to miss blocks compared to attack forks. Therefore, to put the honest fork at an equal footing, the protocol measures fork length as the number of slots spanned, not the number of blocks in it.
2. The branch-off of forks is recent if the forks do not span the entire length of a full epoch. The protocol assumes that the stakes and approvals in such forks are comparable. The protocol also assumes that the block approvals represent approval for the block as well as its ancestry. Therefore, such forks can be compared with approval stake stored in their head blocks.
If the forks have branched off recently, then the fork holding the most approvals in the head block is preferred by the network and is the honest fork.
3. The branch-off is considered long timespan if the unshared part of the forks span at least one whole epoch. In the long timespan, an adversary can manipulate stakes resulting in stakes and approvals in forks to be not comparable. In this case, they are compared for "signatory" stake (described below) in the first block after the branch-off.
There may be accounts on chain that once held large stakes but hold little or no stakes at present. An adversary may be able to acquire private keys of such accounts rather inexpensively. Using these old accounts, they can build attack forks starting a long time in the past and manipulate stakes in them. Therefore, the signatory stake, in the first block after the branch-off, better represents the network's preferences for the forks.
Signatory stake calculation, for each pair of forks, considers only the blocks not shared between them. During the normal operation of the network, some parties have performed some actions requiring them to sign hashes of these unshared blocks. Such actions include:
1. Creating a block.
2. Approving a block.
3. Approving an epoch.
4. Performing a spending transaction, requiring signing hash of an unshared block.
These actions cannot be created without the party's consent or copied to an attack fork. Through these actions, the parties and their entire stake holdings are indicating their testimonials of the corresponding fork.
The signatory stake is the combined stake, of all parties who performed any action requiring their signature, at the first block after the fork branch-off. Note that any testimonial action performed by any party in any successor block adds that party's stake (that it held at the first block after branch-off) to the signatory stake.
If the pair of forks being compared branched-off several weeks or months ago, the honest fork would accumulate testimonials from a large percentage of total stake. With each passing week, more and more parties and their stakes would become signatories on the honest fork. Over time such signatory stake would approach 100%. Note that if parties, that purposely avoid creating or approving blocks, transfer their stake, the very action of transferring their stake makes them signatories.
In long timespan fork comparison, the fork containing the most signatory stake wins. If the branch-off occurred several weeks or months ago, the honest fork would have nearly the entire stake (at the time of branch-off) as the signatory stake. And adversary must control private keys of nearly all stakeholders, at the branch-off time, in order to present a larger signatory stake in their attack fork.
This signatory stake comparison rule makes Proof-of-Approval's defense, against History or Costless Simulation attack, stronger than any other stake based protocol.