[BIP-119] No double space after period, no trailing whitespaces

1 files changed, 9 insertions, 9 deletions

diff --git a/bip-0119.mediawiki b/bip-0119.mediawiki
index 67e21b2..e043f7d 100644
--- a/bip-0119.mediawiki
+++ b/bip-0119.mediawiki
@@ -41,8 +41,8 @@ The recommended standardness rules additionally:
 
 Covenants are restrictions on how a coin may be spent beyond key ownership.
 This is a general definition based on the legal definition which even simple
-scripts using CSV would satisfy.  Covenants in Bitcoin transactions usually
-refer to restrictions on where coins can be transferred.  Covenants can be
+scripts using CSV would satisfy. Covenants in Bitcoin transactions usually
+refer to restrictions on where coins can be transferred. Covenants can be
 useful to construct smart contracts. As covenants are complex to implement and
 risk of introducing fungibility discriminants they have not been seriously
 considered for inclusion in Bitcoin.
@@ -51,7 +51,7 @@ This BIP introduces a simple covenant called a *template* which enables a
 limited set of highly valuable use cases without significant risk. BIP-119
 templates allow for non-recursive fully-enumerated covenants with no dynamic
 state. CTV serves as a replacement for a pre-signed transaction oracle, which
-eliminates the trust and interactivity requirements.  Examples of uses include
+eliminates the trust and interactivity requirements. Examples of uses include
 wallet vaults, non-interactive payment channel creation, congestion controlled
 batching, efficient to construct discreet log contracts, and payment pools,
 among many others. For more details on these applications, please see the
@@ -162,7 +162,7 @@ For the avoidance of unclarity, the parameters to be determined are:
     consensus.vDeployments[Consensus::DEPLOYMENT_CHECKTEMPLATEVERIFY].nTimeout = Consensus::BIP9Deployment::NO_TIMEOUT;
     consensus.vDeployments[Consensus::DEPLOYMENT_CHECKTEMPLATEVERIFY].min_activation_height = 0;
 
-Until BIP-119 reaches ACTIVE state and the 
+Until BIP-119 reaches ACTIVE state and the
 SCRIPT_VERIFY_DEFAULT_CHECK_TEMPLATE_VERIFY_HASH flag is enforced, node implementations should (are recommended to)
 execute a NOP4 as SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS (to deny entry to the mempool) for policy and must evaluate as
 a NOP for consensus (during block validation).
@@ -195,7 +195,7 @@ Below we'll discuss the rules one-by-one:
 
 The set of data committed to is a superset of data which can impact the TXID of the transaction,
 other than the inputs. This ensures that for a given known input, the TXIDs can also be known ahead
-of time.  Otherwise, CHECKTEMPLATEVERIFY would not be usable for Batched Channel Creation constructions
+of time. Otherwise, CHECKTEMPLATEVERIFY would not be usable for Batched Channel Creation constructions
 as the redemption TXID could be malleated and pre-signed transactions invalidated, unless the channels
 are built using an Eltoo-like protocol. Note that there may be other types of pre-signed contracts that
 may or may not be able to use Eltoo-like constructs, therefore making TXIDs predictable makes CTV more
@@ -341,7 +341,7 @@ programs.
 
 RIPEMD160, a 20 byte hash, might also be a viable hash in some contexts and has some benefits. For fee efficiency,
 RIPEMD160 saves 12 bytes. However, RIPEMD160 was not chosen for BIP-119 because it introduces
-risks around the verification of programs created by third parties to be subject to a 
+risks around the verification of programs created by third parties to be subject to a
 [birthday-attack https://bitcoin.stackexchange.com/questions/54841/birthday-attack-on-p2sh] on
 transaction preimages.
 
@@ -523,11 +523,11 @@ CHECKTEMPLATEVERIFY has benefits in terms of script size (depending on choice of
 PK, SIGHASH_ANYPREVOUTANYSCRIPT may use about 2x-3x the bytes) and verification
 speed, as OP_CHECKTEMPLATEVERIFY requires only hash computation rather than
 signature operations. This can be significant when constructing large payment
-trees or programmatic compilations.  CHECKTEMPLATEVERIFY also has a feature-wise
+trees or programmatic compilations. CHECKTEMPLATEVERIFY also has a feature-wise
 benefit in that it provides a robust pathway for future template upgrades.
 
 OP_CHECKSIGFROMSTACKVERIFY along with OP_CAT may also be used to emulate
-CHECKTEMPLATEVERIFY.  However such constructions are more complicated to use
+CHECKTEMPLATEVERIFY. However such constructions are more complicated to use
 than CHECKTEMPLATEVERIFY, and encumbers additional verification overhead absent
 from CHECKTEMPLATEVERIFY. These types of covenants also bear similar potential
 recursion issues to OP_COV which make it unlikely for inclusion in Bitcoin.
@@ -545,7 +545,7 @@ the future as well as synergies with other possible upgrades.
 =====CHECKTEMPLATEVERIFY Versions=====
 
 OP_CHECKTEMPLATEVERIFY currently only verifies properties of 32 byte arguments.
-In the future, meaning could be ascribed to other length arguments.  For
+In the future, meaning could be ascribed to other length arguments. For
 example, a 33-byte argument could just the last byte as a control program. In
 that case, DefaultCheckTemplateVerifyHash could be computed when the flag byte
 is set to CTVHASH_ALL. Other programs could be added similar to SIGHASH_TYPEs.