CH07: s/BIP-xx/BIPxx/

This is my personal preference.  I think it's maximally concise and
reasonably clear.  It's also popular, which aids in searching.

chapters/authorization-authentication.adoc

@@ -608,9 +608,9 @@ If the redeemScript hash matches, the redeemScript is executed:
 
 ((("scripting", "Pay-to-Script-Hash",
 "addresses")))((("Pay-to-Script-Hash (P2SH)", "addresses")))((("bitcoin
-improvement proposals", "Address Format for P2SH (BIP-13)")))Another
+improvement proposals", "Address Format for P2SH (BIP13)")))Another
 important part of the P2SH feature is the ability to encode a script
-hash as an address, as defined in BIP-13. P2SH addresses are Base58Check
+hash as an address, as defined in BIP13. P2SH addresses are Base58Check
 encodings of the 20-byte hash of a script, just like Bitcoin addresses
 are Base58Check encodings of the 20-byte hash of a public key. P2SH
 addresses use the version prefix "5," which results in
@@ -809,10 +809,10 @@ Lock Time Verify (CLTV)")))((("scripting", "timelocks", "Check Lock Time
 Verify (CLTV)")))((("bitcoin improvement proposals",
 "CHECKLOCKTIMEVERIFY (BIP-65)")))In December 2015, a new form of
 timelock was introduced to Bitcoin as a soft fork upgrade. Based on a
-specification in BIP-65, a new script operator called
 _CHECKLOCKTIMEVERIFY_ (_CLTV_) was added to the scripting language.
 +CLTV+ is a per-output timelock, rather than a per-transaction timelock
 as is the case with +nLocktime+. This allows for much greater
+specification in BIP65, a new script operator called
 flexibility in the way timelocks are applied.
 
 In simple terms, by adding the +CLTV+ opcode in the redeemScript of an
@@ -870,7 +870,7 @@ operation” or NOP opcode was executed). Otherwise, script
 execution halts and the transaction is deemed invalid.
 
 More precisely, +CHECKLOCKTIMEVERIFY+ fails and halts execution, marking
-the transaction invalid if (source: BIP-65):
+the transaction invalid if (source: BIP65):
 
 1. the stack is empty; or
 1. the top item on the stack is less than 0; or
@@ -903,8 +903,8 @@ language, +CLTV+ allows us to develop some very interesting complex
 scripts.((("", startref="cltv07")))
 
 The standard is defined in
-https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki[BIP-65
-(CHECKLOCKTIMEVERIFY)].
+https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki[BIP65
+(OP_CHECKLOCKTIMEVERIFY)].
 
 ==== Relative Timelocks
 
@@ -932,15 +932,15 @@ transaction input. Script-level relative timelocks are implemented with
 the +CHECKSEQUENCEVERIFY+ (CSV) opcode.
 
 ((("bitcoin improvement proposals", "Relative lock-time using
-consensus-enforced sequence numbers (BIP-68)")))((("bitcoin improvement
-proposals", "CHECKSEQUENCEVERIFY (BIP-112)")))Relative timelocks are
+consensus-enforced sequence numbers (BIP68)")))((("bitcoin improvement
+proposals", "CHECKSEQUENCEVERIFY (BIP112)")))Relative timelocks are
 implemented according to the specifications in
-https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki[BIP-68,
+https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki[BIP68,
 Relative lock-time using consensus-enforced sequence numbers] and
-https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki[BIP-112,
-CHECKSEQUENCEVERIFY].
+https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki[BIP112,
+OP_CHECKSEQUENCEVERIFY].
 
-BIP-68 and BIP-112 were activated in May 2016 as a soft fork upgrade to
+BIP68 and BIP112 were activated in May 2016 as a soft fork upgrade to
 the consensus rules.
 
 ==== Relative Timelocks with CSV
@@ -970,8 +970,8 @@ specified in the relative timelock. One application of this use case can
 be seen in <<state_channels>> and <<lightning_network>>.((("",
 startref="relativetime07")))((("", startref="Trelative07")))
 
-+CSV+ is defined in detail in
-https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki[BIP-112,
++OP_CSV+ is defined in detail in
+https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki[BIP112,
 CHECKSEQUENCEVERIFY].
 
 === Scripts with Flow Control (Conditional Clauses)