Finality

[sternhenri]

After talking with @sa8 and @ZenGround0, it seems there are really two different paths here.

• probabilistic finality
• byzantine finality

The first is a question of having some sensible heuristic for Filecoin confirmation time, akin to the 6 blocks of Bitcoin. We can call this "probabilistic finality" as in "it's unlikely for someone to come and fork ahead of this" but the fact is it may only be expensive to do so. We think this will be a useful heuristic to have for FIL but given the number of simplifying assumptions that will have to be made in order to quantify the cost of running an attack, it won't really hold outside of these assumptions and will be useful to reason about using Filecoin, not in order to reason formally about finality.

Therefore, we would like to also explore byzantine Finality as is worked in Fantomette, though we want to look into what Algorand also brings to the table here (re committee selection) to help this scale in the number of miners. This will imply 2/3 honest (or rational?) majority, but will give Filecoin a decentralized checkpointing system we can actually rely on.

Any thoughts @whyrusleeping @nicola @jbenet. We will proceed until there is good reason not to :D

[sternhenri]

see https://github.com/filecoin-project/consensus/pull/62

[sternhenri]

TODO: graph a la doublespend table 2 for

• EC w headstart
• EC wo headstart
• EC wo tipsets

[mhammersley]

estimate from @sternhenri is that this is done by aug 30

[sternhenri]

closed based on https://observablehq.com/d/432bc3aeac0ca166

Further work may remain by way of proofs of resiliency vs grinding, long range attacks (forthcoming) and potential future addition of decentralized checkpointing