update README

1 files changed, 7 insertions, 3 deletions

diff --git a/41.md b/41.md
index 7ab54c7..5c6d801 100644
--- a/41.md
+++ b/41.md
@@ -76,13 +76,17 @@ When users who follow the old pubkey see a `kind:1777` event they SHOULD:
 
 After validating all these checks clients SHOULD replace the old pubkey in the user's follow list with the new one.
 
-### Notes
+## Notes
 
-#### Rational behind the 30 days delay
+### Rational behind the 30 days delay
 This gives enough time for a user to notice a migration request published by an attacker and gives the user enough time to publish a competing migration request pointing to an earlier `kind:1776` whitelisting event.
 
-#### Preventing unpublished evil `kind:1777` attack
+### Preventing unpublished evil `kind:1777` attack
 Clients should keep track of when a `kind:1777` event should take into effect, counting at least 30 days from the time of seeing the event and not trusting the event timestamp. This is to prevent an attacker creating an evil `kind:1776`, its attestation, and a `kind:1777` event with its attestation and not publishing them until the 30 days of the attestation have elapsed.
 
 #### Preventing poorly-distributed evil `kind:1777` attack
 Additionally, clients SHOULD broadcast the `kind:1777` events to the relays it normally writes to. This is to prevent an attacker from creating a short-lived NIP-65 relay list where only a subset of users will see an evil `kind:1777` event but not widespread enough for the real owner to notice it.
+
+### Future Work
+
+Key migration can be done in multiple ways. This is an initial implementation that can work. This mechanism should be extended with other, alternative mechanisms, that can leverage different flows/tradeoffs (e.g. social recovery).
\ No newline at end of file