Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using EPs rather than tickets to extend ticket chain with multiple blocks in a TS #472

Closed
sternhenri opened this issue Sep 5, 2019 · 1 comment

Comments

@sternhenri
Copy link
Contributor

sternhenri commented Sep 5, 2019

This issue came up as part of #453.

The proposal is to swap ticket comparison for EP comparison in EC when trying to take appropriate ticket from the ticket-chain:

  • The complexity of having to deal with multiple blocks in a TS from which to pick a ticket can easily be removed by having ticket selection in TipSets be done based the same little-endian bytewise comparison of ElectionProofs.
  1. ElectionProofs and tickets have the same randomness properties: both go through VRFs for their miners (and the VDF adds no randomness)
  2. Tickets remain used as before for randomness, simply the ticket-chain ticket inclusion rule is based on EPs rather than the final ticket

In order for EPs to be valid, our VRFs output must be pseudorandom, meaning any EP will be randomly drawn from [0, 1].
Now, it is indeed true that these EPs will be included in a TS or not based on their miners' power, meaning Pr(EP is smallest in TS|miner is small) > Pr(EP is smallest in TS|miner is large).

The below shows that this impacts their respective chances of winning. A solution may be to hash the EPs again and pick the min of that hash. Otherwise leave as is.


Specifically we can model the above probabilities by reducing power to part of a large
discrete set between 0 and 1, and for various alphas comparing winning EPs (where
their value is beta st beta <= alpha).
We get:
- Pr(minEP | alpha) = 1 - alpha

For two miners with powers alpha1, alpha2
where alpha1 < alpha2
--> Pr(minEP | alpha1) > Pr(minEP | alpha2) by alpha2-alpha1.

However, the overall likelihood that each miner scratch a winning ticket in the first
place is, respectively, alpha1 and alpha2.

Thus we can quantify the following Probas:
Pr(alpha1Wins)
= alpha1 * (Pr(singleWinner) + (1-Pr(singleWinner))* (1-alpha1))
= alpha1 + alpha1^2*(Pr(singleWinner) - 1)

Pr(alpha2Wins)
= alpha2 * (Pr(singleWinner) + (1-Pr(singleWinner))*(1-alpha2))
= alpha2 + alpha2^2*(Pr(singleWinner) - 1)

with alpha1 < alpha2, hence Pr(alpha1Wins) < Pr(alpha2Wins), so far so good.
However Pr(alpha2Wins) - Pr(alpha1Wins)
= (alpha2 - alpha1) + (alpha2^2*(Pr(SW) - 1) - alpha1^2*(Pr(SW) - 1))

rather than what it used to be: alpha2 - alpha1.
@sternhenri
Copy link
Contributor Author

Thoughts @whyrusleeping @jzimmerman @ZenGround0 ?

It seems counterintuitive to me that this would change their probas of winning so where am I wrong here?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants