From d2a9b14a9753d94b03d88869ff256f63be5c2de6 Mon Sep 17 00:00:00 2001
From: brqgoo <100725376+brqgoo@users.noreply.github.com>
Date: Mon, 16 Jan 2023 17:37:05 +0300
Subject: [PATCH] Update 04.md

---
 04.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/04.md b/04.md
index 2de7259..e1271ea 100644
--- a/04.md
+++ b/04.md
@@ -34,8 +34,8 @@ When a sender wants to pay the recipient, the sender initiates a swap-in payment
 * The sender generates a 32-byte random element `rand`
 * The sender calculates a tweaked pubkey for the recipient: `R' = hash(s*R, rand)*G + R`.
 * The sender generates a shared preimage secret for the recipient : `P = hash(rand)*G + R`
-* The sender `S` then sends a [NIP-04](https://github.com/nostr-protocol/nips/blob/329cd8d8a19fd1dcb12df7eb7a5d640b2a5b6bf8/04.md) encrypted DM to the recipient containing rand and payment value.
-* The recipient `R` can locally construct his tweaked pubkey `R'` and preimage `P` from the rand value, and the sender's npub `S`.
+* The sender `S` then sends a [NIP-04](https://github.com/nostr-protocol/nips/blob/329cd8d8a19fd1dcb12df7eb7a5d640b2a5b6bf8/04.md) encrypted DM to the recipient containing `rand` and payment value.
+* The recipient `R` can locally construct his tweaked pubkey `R'` and preimage `P` from the `rand` value, and the sender's npub `S`.
 
 
 Although it seems similar to keysend due to the sender generating the preimage, the proof of payment here is not the revealed preimage but the on-chain transaction (swap factory) itself.