Added more detail to "bridge" chapter

06_lightning_architecture.asciidoc

@@ -25,3 +25,31 @@ Peer-2-Peer (P2P) Layer:: This layer is primary protocol layer for communication
 Routing Layer:: This layer contains the protocols used to route payments between nodes, end-to-end and atomically. This layer contains the "core" functionality of the Lightning Network: routed payments.
 
 Payment Layer:: The highest layer of the network, which presents a reliable payment interface to applications.
+
+=== Lightning in Detail
+
+Over the next 10 chapters, we will diseect the protocol suite and examine each component of the Lightning Network in detail.
+
+We spent quite some time trying to decide the best order of presenting this detail. It's not an easy choice as there is so much interdependence between different components: as you start explaining one, you find that it pulls in quite a few of the other componenents. Instead of a top-down or bottom-up approach, we ended up choosing a more meandering path that starts with the most fundamental building blocks that are unique to the Lightning Network - Payment Channels - and moves outwards from there. But since that path is not obvious, we will use the Lightning Protocol Suite shown in <<lightning_network_protocol_suite>> as a map. In each chapter will focus on one or more related components, and you will see them highlighted in the protocol suite. Kind of like a map marker saying "You are here!".
+
+Here's what we will cover:
+
+<<payment_channels>>:: In this chapter we will look at how payment channels work, in significantly more depth than we saw in the earlier parts of the book. We will look at the structure and Bitcoin Script of the funding and commitment transactions and the process used by nodes to negotiate each step in the protocol.
+
+<<routing_htlcs>>:: Next, we will put together several payment channels in a network and route a payment from one end to the other. In that process we will dive into the Hash Time-Locked Contract smart contract and the Bitcoin Script that we use to construct it.
+
+<<channel_operation>>:: Putting together the concepts of a simple payment channel and a routed payment using HTLCs, we will now look at how HTLCs are part of each channel's commitment transaction. We will also look at the protocol for adding, settling, failing and removing HTLCs from the commitments.
+
+<<onion_routing>>:: Next, we will look at how the HTLC information is propagated across the network inside the onion routing protocol. We will look at the mechanism for layered encryption and decryption that gives the Lightning Network some of its privacy characteristics.
+
+<<gossip>>:: In this chapter we will look at how Lightning nodes find each other and learn about published channels, in order to construct a channel graph that they can use to find paths across the network.
+
+<<path_finding>>:: Next, we will see how the information from the gossip protocol is used by each node to build a "map" of the entire network, which it can use to find paths from one point to another to route payments. We'll also look at the exiting innovations in path finding such as multi-part payments.
+
+<<payment_requests>>:: A key part of the Lightning Network are payment requests, also known as Lighting Invoices. In this chapter we dissect the structure and encoding of an invoice.
+
+<<wire_protocol>>:: Underpinning the Lightning Network is the Peer-to-Peer protocol that nodes use to exchange messages about the network and about their channels. In this chapter we look at how those messages are constructed and the extension capabilities built into messages with feature bits and TLV encoding.
+
+<<encrypted_transport>>:: Moving down to the lower-level part of the network, we will look at the underlying encrypted transport system that ensures the secrecy and integrity of all communications between nodes.
+
+Let's dive in!