# PTC functioning


PTC functioning:
- Proposer: if your sampling is not satisfied, don't extend the payload. If it is, and you see > 25% yes votes, extend the payload. If you see < 25% yes votes, don't extend the payload. Equivocations nullify the votes (same as how they are counted in the fork choice currently)
- Next slot attesters: at the PTC deadline, freeze your view of payload availability, based on your sampling. When attesting, if your *current* view of availability is "no", enforce that the payload is *not* extended. If it is "yes", allow the proposer to extend it: if the proposer extends it, always vote for it. If it is "yes" but was "no" at the deadline (the frozen view) or the PTC votes are < 50% yes (removing equivocations), allow the proposer to *not* extend it. If it is "yes", was "yes" at the deadline and the PTC is > 50% yes, enforce that it is extended

Guarantees:
- honest proposal in slot N => (yes, yes, > 50) => payload canonical (attesters in N+1 vote for it regardless)
- honest proposer sampling not satisfied => it wasn't available at PTC deadline => frozen views are "no" => not extending is an allowed choice (this is even if the PTC was corrupted)
- honest proposer sees < 25% => it won't get to 50% => not extending is an allowed choice
- honest proposer sees > 25% => it is available => honest views are "yes" at the attestation deadline => extending is allowed
- payload is not available => most attesters' view at the attestation deadline is "no" and they vote against

Attacks if you control some of the PTC:
1. If you control > 25% of the PTC (to vote "yes") *and* you can target the proposer and reveal only the data it wants, the proposer will extend the payload but attesters will vote against it because their sampling fails. This (selectively revealing data the proposer wants) is why we have the PTC in the first place, to have this second layer of defense.
2. If you control > 50% of the PTC *and* the next proposer, you can reorg a good payload, by having the proposer not extend it and > 50% of the PTC vote against it, so that the attesters are ok with the proposer not extending it
3. If you control > 75% of the PTC, you can get the next proposer to not extend a good payload (they see < 25% PTC) and the next attesters to accept that

Supernode proposers are immune to 1., because there is no way to convince them that the data is available when it is not. We could also remove 3. as an attack vector in supernode proposer slots by having them completely ignore the PTC, since they don't need it to protect themselves (from selective reveal).


Then the only ways to abuse the PTC would be:
- Slot N has a non supernode proposer:
- 25% of the PTC: Reorg slot N (attack 1.)
- 75% of the PTC: Reorg slot N-1 (attack 3.)
- Reorging any payload *when colluding with the proposer of the next slot* and controlling 50% of the PTC (attack 2. from before)