Edited 15_payment_requests.asciidoc with Atlas code editor

15_payment_requests.asciidoc

@@ -24,7 +24,7 @@ to complete a payment from receiver to sender is described in https://github.com
 payment hash and destination are communicated in a payment request to
 make the encoding more fully featured.
 
-=== Lightning Payment Requests versus Bitcoin Addresses
+=== Lightning Payment Requests Versus Bitcoin Addresses
 
 ((("Bitcoin addresses, Lightning invoices versus")))((("Lightning invoices","Bitcoin addresses versus")))A commonly asked question when people first encounter a Lightning Payment
 request is: why can't a normal static address format be used instead?
@@ -57,7 +57,7 @@ a mechanism that allows a sender to typically request a new payment request
 from the receiver, then an interactive protocol can be used to allow a
 degree of payment request reuse.
 
-=== BOLT #11: Lightning Payment Request Serialization and Interpretation
+=== BOLT #11: Lightning Payment Request Serialization pass:[<span class="keep-together">and Interpretation</span>]
 
 ((("BOLT (Basis of Lightning Technology) standards documents","Lightning payment request serialization/interpretation")))((("Lightning invoices","payment request serialization/interpretation")))In this section, we'll describe the mechanism used to encode the set of
 information required to complete a payment on the Lightning Network. As
@@ -183,7 +183,7 @@ A full list of all the currently defined tagged fields is given in <<table1503>>
 .BOLT #11 tagged invoice fields
 [options="header"]
 |===
-|Field tag|Data length|Usage
+|pass:[<span class="keep-together">Field tag</span>]|pass:[<span class="keep-together">Data Length</span>]|Usage
 |`p`|`52`|The SHA-256 payment hash.
 |`s`|`52`|A 256-bit secret that increases the end-to-end privacy of a payment by mitigating probing by intermediate nodes.
 |`d`|Variable|The description, a short UTF-8 string of the purpose of the payment.