Apply suggestions from code review

Co-authored-by: Oleksandr Tkachenko <[email protected]>

spec/index.md

@@ -2445,9 +2445,9 @@ The encoding of the signature depends on the key ID's `algorithm`:
 
 -   For algorithm `ed25519`, the signature is encoded in 64 bytes according to [RFC8032, 5.1.6 Sign](https://datatracker.ietf.org/doc/html/rfc8032#section-5.1.6).
 
-This call requires that a Schnorr key with ID `key_id` was generated by the IC and the signing functionality for that key was enabled. Otherwise, the call is is rejected.
+This call requires that a Schnorr key with ID `key_id` was generated by the IC and the signing functionality for that key was enabled. Otherwise, the call is rejected.
 
-This call accepts an optional auxiliary parameter `aux`. The auxiliary parameter type `schnorr_aux` is a variant. The only currently supported variant is `bip341` which allows passing a Merkle tree root hash, which is required to implement Taproot signatures as defined in [BIP341](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki). The `bip341` variant is anly allowed for `bip340secp256k1` signatures, and if provided the `merkle_root_hash` blob must be exactly 32 bytes long, and should be generated in accordance with BIP341's specification for `taproot_output_script`. If no auxiliary parameter is provided, then `bip340secp256k1` signatures are generated in accordance with BIP340.
+This call accepts an optional auxiliary parameter `aux`. The auxiliary parameter type `schnorr_aux` is a variant. The only currently supported variant is `bip341` which allows passing a Merkle tree root hash, which is required to implement Taproot signatures as defined in [BIP341](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki). The `bip341` variant is only allowed for `bip340secp256k1` signatures, and if provided the `merkle_root_hash` blob must be exactly 32 bytes long, and should be generated in accordance with BIP341's specification for `taproot_output_script`. If no auxiliary parameter is provided, then `bip340secp256k1` signatures are generated in accordance with BIP340.
 
 Cycles to pay for the call must be explicitly transferred with the call, i.e., they are not automatically deducted from the caller's balance implicitly (e.g., as for inter-canister calls).