From dcc83586848d432a1488512b69dadcfe8d3d7637 Mon Sep 17 00:00:00 2001
From: Bitcoin Txoko <142011724+bitcointxoko@users.noreply.github.com>
Date: Wed, 4 Dec 2024 15:34:30 +0100
Subject: [PATCH] Update ln-07.md

---
 en/ln-07.md | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/en/ln-07.md b/en/ln-07.md
index 84842d7..26f16ed 100644
--- a/en/ln-07.md
+++ b/en/ln-07.md
@@ -288,3 +288,9 @@ The `your_last_per_commitment_secret` is the last per-commitment secret received
 There are lots of checks that a node should do when receiving a `channel_reestablish` in order to make sure that all necessary updates are re-sent so that the channel can continue working as normal. There are also some checks that ensure that nodes are not tricked into revoking a state that should not yet be revoked or tricked into broadcasting a state that _has_ been revoked. If you are interested in the details around these checks, read [BOLT2](https://github.com/lightning/bolts/blob/master/02-peer-protocol.md). 
 
 Note that when a connection re-establish happens, both sides must remove any uncommitted updates from their staging area. If we revisit the git analogy, they should use git stash when a reconnection occurs. This means that both sides will need to retransmit any `update_*` messages that were not yet committed on the other side's commitment transaction. 
+
+### References
+- [BOLT2 Peer Protocol](https://github.com/lightning/bolts/blob/master/02-peer-protocol.md)
+- [Normal Operation of a pre-taproot LN channel](https://ellemouton.com/posts/normal-operation-pre-taproot/) by nostr:nprofile1qqswrt9pnxatlplu49h6meld8svmwqt87wwvk256rqk07n6eu4qeh5gpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dszpfjtz
+- [A Technical Walkthrough of Hash Time Locked Contracts and Lightning Channel Operations](https://lightning.engineering/posts/2023-06-28-channel-normal-op/)
+- [BOLT8 Transport](https://github.com/lightning/bolts/blob/master/08-transport.md)