Update docs/_blog/introducing-rapid-gossip-sync.md

Co-authored-by: Haley Berkoe <94868372+haleyberkoe@users.noreply.github.com>

Author: Conor Okus

docs/_blog/introducing-rapid-gossip-sync.md

@@ -19,7 +19,7 @@ For that reason, we're very excited to announce Rapid Gossip Sync, a protocol th
 
 Before we delve too deeply into the optimizations that Rapid Gossip Sync relies on, first a primer on how gossip works today. It involves three main message types: channel announcements, channel updates, and node announcements. (The last of which isn’t really relevant to this post.)
 
-As their names imply, channel announcements are sent when a public channel opens, and updates when changes are made to a channel. One peculiar characteristic of channels is that they aren't symmetrical: depending on the direction, some of their properties may vary. For instance, if Alice and Bob have a channel, Alice may charge higher fees for forwarding payments to Bob than vice versa, thus requiring that different channel updates be broadcast to the network for each direction. Just as balances may concentrate on one side, routing fees for forwarding payments through the channel are set by different parties depending on the direction. Unlike channel updates, channel announcements do not carry directional information, meaning opening a new channel requires sending at least two channel updates for direction-specific data.
+As their names imply, channel announcements are sent when a public channel opens, and updates when changes are made to a channel. One peculiar characteristic of channels is that they aren't symmetrical: depending on the direction, some of their properties may vary. For instance, if Alice and Bob have a channel, Alice may charge higher fees for forwarding payments to Bob than Bob to Alice. Unlike channel updates, channel announcements do not carry directional information, so that scenario would require that different channel updates be broadcast to the network for each direction. Similarly, opening a new channel also requires sending at least two channel updates to initialize direction-specific properties.
 
 One of the noteworthy properties of gossip is that a lot of data is duplicated across messages. For example, each channel announcement and update contains the genesis block hash. Similarly, each channel announcement contains both nodes’ public keys, exacerbating data redundancy for well-connected nodes. So, to reduce bandwidth requirements, we decided to see if we could strip data to create a more efficient way of conveying the same information.