From a80ff2f69fdbfde19620e0820ad7222b8ebe0dfd Mon Sep 17 00:00:00 2001 From: Erik Johnston Date: Mon, 5 Nov 2018 09:45:11 +0000 Subject: [PATCH] Don't use rejected auth events --- proposals/1442-state-resolution.md | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/proposals/1442-state-resolution.md b/proposals/1442-state-resolution.md index a07b67558..c908d8d0d 100644 --- a/proposals/1442-state-resolution.md +++ b/proposals/1442-state-resolution.md @@ -285,8 +285,8 @@ First we define: 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). + exist in the state, then the one in the event's auth_events is used if the + auth event is not rejected. (See _Variations_ and _Attack Vectors_ below). The algorithm proceeds as follows: @@ -446,7 +446,7 @@ reapply the unconflicted state at the end). Events that have been rejected due to failing auth based on the state at the event (rather than based on their auth chain) are handled as usual by the -algorithm. +algorithm, unless otherwise specified. 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 (and the @@ -473,6 +473,10 @@ Intuitively using rejected events feels dangerous, however: duplicated event will pass auth. Therefore ignoring rejected events wouldn't reduce any potential attack vectors +We specifically don't use rejected auth events in the iterative auth checks, as +in that case the auth events aren't re-authed like the rest of the events in the +list. + ### Attack Vectors