Fix typo: "specific" -> "specifics"

11_gossip_channel_graph.asciidoc

@@ -290,7 +290,7 @@ base Bitcoin blockchain means that it's impossible to _fake_ a valid channel gra
 
 +channel_update+:: A _pair_ of structures that describes the set of routing policies for a given channel. +channel_update+ messages come in a _pair_ because a channel is a directed edge, so each side of the channel is able to specify its own custom routing policy.
 
-It's important to note that each component of the channel graph is _authenticated_, allowing a third party to ensure that the owner of a channel/update/node is actually the one sending out an update. This effectively makes the channel graph a unique type of _authenticated data structure_ that cannot be counterfeited. For authentication, we use an +secp256k1+ ECDSA digital signature (or a series of them) over the serialized digest of the message itself. We won't get into the specific of the messaging framing/serialization used in the Lightning Network in this chapter, as we'll cover that information in <<wire_protocol>>.
+It's important to note that each component of the channel graph is _authenticated_, allowing a third party to ensure that the owner of a channel/update/node is actually the one sending out an update. This effectively makes the channel graph a unique type of _authenticated data structure_ that cannot be counterfeited. For authentication, we use an +secp256k1+ ECDSA digital signature (or a series of them) over the serialized digest of the message itself. We won't get into the specifics of the messaging framing/serialization used in the Lightning Network in this chapter, as we'll cover that information in <<wire_protocol>>.
 
 With the high-level structure of the channel graph laid out, we'll now dive down into the precise structure of each of the three messages used to gossip the channel graph. We'll also explain how one can also verify each message and component of the channel graph.