diff --git a/bip-bod-descriptors.mediawiki b/bip-bod-descriptors.mediawiki
index 58a6165931..f59d20f54b 100644
--- a/bip-bod-descriptors.mediawiki
+++ b/bip-bod-descriptors.mediawiki
@@ -42,7 +42,7 @@ software).</ref>
 <ref> '''Why not use the older Blockchain Commons BCR-2020-010 format?'''
 The format was [[https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2020-010-output-desc.md#deprecated-superseded-by-version-3-output-descriptors|recently deprecated]],
 due to its use of reserved CBOR tags.</ref>
-<ref>'''Why not use the new Blockchain Commons BCR-2023-010 format?'''.
+<ref>'''Why not use the new Blockchain Commons BCR-2023-010 format?'''
 The [[https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-2023-010-output-descriptor.md|BCR-2023-010 format]]
 is roughly equivalent to this proposal, but was designed and released outside of
 the usual BIP proposal process.
@@ -60,8 +60,8 @@ support at the time of this writing.</ref>.
 ==Specification==
 
 The Binary Output Descriptor (BOD) format consists of a fixed header, a
-key-value map describing the output descriptor and its metadata followed by a
-map for each key referenced by the descriptor.
+key-value map describing the output descriptor, and a key-value map for
+each key.
 
  <bod> := <magic> <global-map> <key-map>*
  <magic> := 0x62 0x6F 0x64 0xFF
@@ -86,13 +86,13 @@ The defined global types are as follows:
 | The earliest block height that may contain transactions for the descriptor, optionally followed by the UTF-8 encoded name of the descriptor.
 | <tt><bytes descriptor></tt>
 | The output descriptor in BIP 380 format without inline keys<ref>''Why not encode the descriptor in binary?'''
-The BIP 380 descriptor language is complicated and expanding, and we believe
-the effort of designing a parallel binary encoding does not outweigh the
-space savings.
+Designing and maintaining a compact binary representation of the complex and evolving BIP 380 descriptor
+language entail significant effort and introduce a time lag from the introduction of new BIP 380 features
+to the spcification of the binary counterpart. We don't believe the space savings outweigh the disadvantages.
 
 The major source of bloat, base58-encoded keys, are binary encoded for compactness and
 can be re-used multiple times in a single descriptor.
-.</ref>
+</ref>.
 |-
 | Proprietary Use Type
 | <tt>BOD_GLOBAL_PROPRIETARY = 0xFC</tt>