Require commitment input syntactically

tips/TIP-0042/tip-0042.md

@@ -237,12 +237,15 @@ disincentivize account owners to overspend their BIC.
   - The `Block Issuer Keys` must be lexically ordered and unique, both based on the following comparison criteria:
     - `Block Issuer Key Type` as the first criteria for all Block Issuer Keys.
     - `Pub Key Hash` as the second criteria for _Ed25519 Public Key Hash Block Issuer Keys_.
+  - A _Commitment Input_ must be present in the transaction.
 
 ### Additional Transaction Semantic Validation Rules
 
 - When a _Block Issuer Feature_ is present in an account on the input or output side of a transaction, the transaction
-  that contains this output is valid, if and only if:
+  is valid only if:
   - A _Commitment Input_ is present.
+- When a _Block Issuer Feature_ is present in an account on the input side of a transaction, the transaction is valid
+  only if:
   - A _Block Issuance Credit Input_ is present whose `Account ID` equals that of the account being transitioned.
 - Let `Commitment Index` be the slot index of the _Commitment Input_.
 - Let `Past Bounded Slot Index` be given by `Commitment Index + Max Committable Age`.
@@ -357,26 +360,27 @@ which they were selected to participate in the validator committee.
 ### Additional Transaction Syntactic Validation Rules
 
 - The `Amount` in the containing account output satisfies `Amount >= Staked Amount`.
+- A _Commitment Input_ must be present in the transaction.
 
 ### Additional Transaction Semantic Validation Rules
 
 - Let `Future Bounded Epoch Index` be the epoch index corresponding to the slot index given by
   `Commitment Index + Min Committable Age` where `Commitment Index` is the slot index of the commitment input.
 - Let `Past Bounded Epoch Index` be the epoch index corresponding to the slot index given by
   `Commitment Index + Max Committable Age` where `Commitment Index` is the slot index of the commitment input.
-- When a _Staking Feature_ is present in an account output on the input or output side of a transaction, the transaction
-  that contains this output is valid, if and only if:
+- When a _Staking Feature_ is present in an account output on the input side of a transaction, the transaction that
+  contains this output is valid only if:
   - A _Commitment Input_ is present.
 - When a _Staking Feature_ is present in an account output on the output side of a transaction, the transaction that
-  contains this output is valid, if and only if all of the following conditions hold:
+  contains this output is valid only if all of the following conditions hold:
   - A _Block Issuer Feature_ must be present in the account.
 - When a _Staking Feature_ is present in an account output on the output side of a transaction and the feature was not
-  present on the input side, the transaction that contains this output is valid, if and only if all of the following
-  conditions hold:
+  present on the input side, the transaction that contains this output is valid only if all of the following conditions
+  hold:
   - `Start Epoch` must be set to `Past Bounded Epoch Index`.
   - `End Epoch` satisfies `End Epoch >= Past Bounded Epoch Index + Staking Unbonding Period`.
 - When a _Staking Feature_ is present in an account output on the input side of a transaction, the transaction that
-  contains this input is valid, if and only if all of the following conditions hold:
+  contains this input is valid only if all of the following conditions hold:
   - If `Future Bounded Epoch Index <= End Epoch`, all of the following conditions must hold:
     - A _Staking Feature_ must be present on the corresponding account on the output side of the transaction.
     - The fields `Staked Amount`, `Start Epoch` and `Fixed Cost` on the feature on the input and the feature on the