diff --git a/proposals/2176-update-redaction-rules.md b/proposals/2176-update-redaction-rules.md
new file mode 100644
index 00000000..574028f2
--- /dev/null
+++ b/proposals/2176-update-redaction-rules.md
@@ -0,0 +1,97 @@
+# MSC2176: Update the redaction rules
+
+The current [redaction
+algorithm](https://matrix.org/docs/spec/client_server/r0.5.0#redactions) is now
+somewhat dated. This MSC proposes a number of changes to the rules which will
+improve the security and reliability of the Matrix protocol.
+
+## Proposal
+
+The following changes will require a new room version, since changes to the
+redaction algorithm also change the way that [event
+hashes](https://matrix.org/docs/spec/server_server/r0.1.2#calculating-the-reference-hash-for-an-event)
+(and hence event IDs) are calculated.
+
+The following *event* keys are to be *removed* from the list of those to be
+preserved by a redaction:
+
+ * `membership`
+ * `prev_state`
+
+(Note this refers to the *event-level* `membership` property, rather than the
+similarly-named sub-property under the `content` key.)
+
+Rationale: neither of the above properties have defined meanings any more in the Matrix
+protocol, so there is no reason for them to be special-cased in this way.
+
+The following are to be added to the list of subkeys of the content property
+which are preserved:
+
+ * `m.room.create` preserves *all* content. Rationale: the values in a
+   `create` event are deliberately intended to last the lifetime of the room,
+   and if values are redacted, there is no way to add correct settings
+   afterwards. It therefore seems non-sensical to allow redaction of a `create`
+   event.
+
+ * `m.room.redaction` should allow the `redacts` key (assuming
+   [MSC2174](https://github.com/matrix-org/matrix-doc/pull/2174) is merged).
+   Rationale: currently, redacting a redaction can lead to inconsistent results
+   among homservers, depending on whether they receive the `m.room.redaction`
+   result before or after it is redacted (and therefore may or may not redact
+   the original event).
+
+ * `m.room.power_levels` should allow (in addition to the keys already listed
+   in the spec):
+
+   * the `invite` key. Rationale: this is required to authenticate
+     `m.room.member` events with the `invite` membership. Currently, redacting
+     a `power_levels` event will mean that such events cannot be authenticated,
+     potentially leading to a split-brain room.
+
+## Other properties considered for preservation
+
+Currently it is *not* proposed to add these to the list of properties which are
+proposed for a redaction:
+
+ * The `notifications` key of `m.room.power_levels`. Unlike the other
+   properties in `power_levels`, `notifications` does not play a part in
+   authorising the events in the room graph. Once the `power_levels` are
+   replaced, historical values of the `notifications` property are
+   irrelevant. There is therefore no need for it to be protected from
+   redactions.
+
+ * The `algorithm` key of `m.room.encryption`. Again, historical values of
+   `m.room.encryption` have no effect, and servers do not use the value of the
+   property to authenticate events.
+
+   The effect of redacting an `m.room.encryption` event is much the same as that
+   of sending a new `m.room.encryption` event with no `algorithm` key. It's
+   unlikely to be what was intended, but adding rules to the redaction
+   algorithm will not help this.
+
+### Background to things not included in the proposal
+
+The approach taken here has been to minimise the list of properties preserved
+by redaction; in general, the list is limited to those which are required by
+servers to authenticate events in the room. One reason for this is to simplify
+the implementation of servers and clients, but a more important philosophical
+reason is as follows.
+
+Changing the redaction algorithm requires changes to both servers and clients,
+so changes are difficult and will happen rarely. Adding additional keys now
+sets an awkward precedent.
+
+It is likely that in the future more properties will be defined which might be
+convenient to preserve under redaction. One of the two scenarios would then
+happen:
+
+ * We would be forced to issue yet more updates to the redaction algorithm,
+   with a new room versions and mandatory updates to all servers and clients, or:
+
+ * We would end up with an awkward asymmetry between properties which were
+   preserved under this MSC, and those which were introduced later so were not
+   preserved.
+
+In short, I consider it important for the elegance of the Matrix protocol that
+we do not add unnecessary properties to the list of those to be preserved by
+redaction.