From dd045b6d249f546797c5f86a513115ef48e08ac5 Mon Sep 17 00:00:00 2001
From: Bitcoin Txoko <142011724+bitcointxoko@users.noreply.github.com>
Date: Thu, 21 Nov 2024 21:38:20 +0100
Subject: [PATCH] Update ln-03.md

---
 en/ln-03.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/en/ln-03.md b/en/ln-03.md
index 2fd1674..5198f37 100644
--- a/en/ln-03.md
+++ b/en/ln-03.md
@@ -56,7 +56,7 @@ Bob will have:
 Now, when it's time for Alice to construct the commitment transaction, she will send Bob her commitment point pubkey `CA1`. Bob will send her his revocation basepoint pubkey `RB1`. Alice can now derive the revocation pubkey to be included in the commitment transaction as follows:
 
 ```
-Rev_A2 = R_B1 * sha256( R_B1 || C_A1 ) + C_A1 * sha256( C_A1 || R_B1 )
+Rev_A1 = R_B1 * sha256( R_B1 || C_A1 ) + C_A1 * sha256( C_A1 || R_B1 )
 ```
 
 Now Alice's `to_local` output looks like this:
@@ -76,7 +76,7 @@ OP_CHECKSIG
 When it's time for Alice and Bob to update state and invalidate the old state, Alice sends Bob her private key for the commitment point `cA2`. With this key, Bob now has both Alice's per commitment point private key `cA1` as well as his own revocation basepoint private key `rB1` which corresponds to the public key `RB1` he sent Alice earlier when Alice was constructing the commitment transaction. So now with these two pieces of information, Bob can derive the private key corresponding to the public key `Rev_A1` and therefore spend via the revocation output. He can calculate the private key as follows:
 
 ```
-rev_A2 = r_B1 * sha256( R_B1 || C_A1 ) + c_A1 * sha256( C_A1 || R_B1 )
+rev_A1 = r_B1 * sha256( R_B1 || C_A1 ) + c_A1 * sha256( C_A1 || R_B1 )
 ```
 
 Alice will never be able to derive this private key because she does not have and will never have Bob's revocation basepoint private key `rB1`.