From 3d3b77ea7ea11719f3692ea2d8e37ad1d731fed7 Mon Sep 17 00:00:00 2001 From: Erik Johnston Date: Mon, 8 Oct 2018 14:25:06 +0100 Subject: [PATCH] Specify how to handle rejected events in new state res It's possible for events in an an event's auth chain to be rejected due to not having passed auth (based on the state at the time), so we need to be explicit about how to handle that case. --- proposals/1442-state-resolution.md | 28 +++++++++++++++++++++------- 1 file changed, 21 insertions(+), 7 deletions(-) diff --git a/proposals/1442-state-resolution.md b/proposals/1442-state-resolution.md index 1a2e82a3..6994196c 100644 --- a/proposals/1442-state-resolution.md +++ b/proposals/1442-state-resolution.md @@ -244,7 +244,8 @@ First we define: with an absent event to be unconflicted rather than conflicted) * The "**auth difference"** is calculated by first calculating the full auth chain for each state set and taking every event that doesn't appear in every - auth chain. + auth chain. (This includes any events in the auth chain that have been + rejected.) * The **"full conflicted set"** is the union of the conflicted state map and auth difference. * The **"reverse topological power ordering"**[^4] of a set of events is an @@ -269,18 +270,21 @@ First we define: ordered such that P is last. 1. We say the "closest mainline event" of an event is the first power level event encountered in mainline when iteratively descending through the - power level events in the auth events. + power level events in the auth events (including any power level events + that were rejected). 1. Order the set of events such that x < y if: 1. The closest mainline event of x appears strictly before the closest of y in the mainline list, or if 1. x's origin_server_ts is less than y's, or if 1. x's event_id lexicographically sorts before y's * The **"iterative auth checks"** algorithm is where given a sorted list of - events, the auth check algorithm is applied to each event in turn. The state - events used to auth are built up from previous events that passed the auth - checks, starting from a base set of state. If a required auth key doesn't - exist in the state, then the one in the event's auth_events is used. (See - _Variations_ and _Attack Vectors_ below). + events, the auth check algorithm is applied to each event in turn (ignoring + any events have been rejected). The state events used to auth are built up + from previous events that passed the auth checks, starting from a base set + of state. If a required auth key doesn't exist in the state, then the one in + the event's auth_events is used (unless the auth event has been rejected). + (See _Variations_ and _Attack Vectors_ below). + The algorithm proceeds as follows: @@ -436,6 +440,16 @@ a separate auth chain, and the difficulties that entails (like having to reapply the unconflicted state at the end). +### Rejected Events + +We include rejected events in the "auth chain difference" as they can still be +used to effect the ordering of events. This in turn means care must be taken to +filter rejected events out when applying the iterative auth checks. + +Note that no events rejected due to failure to auth against their auth chain +should appear in the process, as they should not appear in state. + + ### Attack Vectors The main potential attack vector that needs to be considered is in the