Add dashes.

1 files changed, 1 insertions, 1 deletions

diff --git a/bip-0090.mediawiki b/bip-0090.mediawiki
index 36ec551..11961f6 100644
--- a/bip-0090.mediawiki
+++ b/bip-0090.mediawiki
@@ -16,7 +16,7 @@ This BIP describes a method to deterministically generate multi-signature transa
 
 Most multi-signature transactions are addressed to P2SH (pay-to-script-hash) addresses, as defined in BIP-0016.
 
-Multi-signature redeem scripts do not require a particular ordering or encoding for public keys.  This means that for a given set of keys and number of required signatures, there are as many as 2(n!) possible standard redeem scripts, each with its separate P2SH address.  Adhering to a an ordering scheme and key encoding would ensure that a multi-signature “account” (set of public keys and required signature count) has a canonical P2SH address.
+Multi-signature redeem scripts do not require a particular ordering or encoding for public keys.  This means that for a given set of keys and number of required signatures, there are as many as 2(n!) possible standard redeem scripts, each with its separate P2SH address.  Adhering to an ordering and key encoding would ensure that a multi-signature “account” (set of public keys and required signature count) has a canonical P2SH address.
 
 By adopting a sorting and encoding standard, compliant wallets will always produce the same P2SH address for the same given set of keys and required signature count, making it easier to recognize transactions involving that multi-signature account.  This is particularly attractive for multisignature hierarchical-deterministic wallets, as less state is required to setup multi-signature accounts:  only the number of required signatures and master public keys of participants need to be shared, and all wallets will generate the same addresses.