Spelling fix and small clarification for BIP 120

Spelling:
  Line 42: "neccesarily" => "necessarily"
  Line 126: "scipts" => "scripts"

One small improvement for clarity:
  Line 138:  "another" => "a different"

1 files changed, 3 insertions, 3 deletions

diff --git a/bip-0120.mediawiki b/bip-0120.mediawiki
index e099f5b..1602c65 100644
--- a/bip-0120.mediawiki
+++ b/bip-0120.mediawiki
@@ -39,7 +39,7 @@ Current methods of proving a payment:
 * In BIP0070, the PaymentRequest together with the transactions fulfilling the request makes some sort of proof. However, it does not meet 1, 2 or 4 and it obviously only meets 3 if the payment is made through BIP0070. Also, there's no standard way to request/provide the proof. If standardized it would probably meet 5.
 * Signing messages, chosen by the server, with the private keys used to sign the transaction. This could meet 1 and 2 but probably not 3. This is not standardized either. 4 Could be met if designed so.
 
-If an input script type is P2SH, any satisfying script should do, just as if it was a payment. For M-of-N multisig scripts, that would mean that any set of M keys should be sufficient, not neccesarily the same set of M keys that signed the transaction. This is important because strictly demanding the same set of M keys would defeat the purpose of a multisig address.
+If an input script type is P2SH, any satisfying script should do, just as if it was a payment. For M-of-N multisig scripts, that would mean that any set of M keys should be sufficient, not necessarily the same set of M keys that signed the transaction. This is important because strictly demanding the same set of M keys would defeat the purpose of a multisig address.
 
 == Specification ==
 
@@ -123,7 +123,7 @@ The server needs to validate the PoP and reply with "valid" or "invalid". That p
 # Check that there is exactly one output. This output must have value 0 and conform to the OP_RETURN output format outlined above.
 # Check that the nonce is the same as the one requested.
 # Check that the inputs of the PoP are exactly the same as in transaction T, except that the sequence numbers must all be 0. The ordering of the inputs must also be the same as in T.
-# Run the scripts of all the inputs. All scipts must return true.
+# Run the scripts of all the inputs. All scripts must return true.
 # Check that the txid in the PoP output is the transaction you actually want proof for. If you don’t know exactly what transaction you want proof for, check that the transaction actually pays for the product/service you deliver.
 # Return "valid".
 
@@ -135,7 +135,7 @@ The server needs to validate the PoP and reply with "valid" or "invalid". That p
 ** nonce - Your pop will not validate on server.
 * Someone can steal a PoP, for example by tampering with the PoP request, and try to use the service hoping to get a matching nonce. Probability per try: 1/(2^48). The server should have a mechanism for detecting a brute force attack of this kind, or at least slow down the process by delaying the PoP request by some 100 ms or so.
 * Even if a wallet has no funds it might still be valuable as a generator for PoPs. This makes it important to keep the security of the wallet after it has been emptied.
-* Transaction malleability may cause the server to have another transaction id for a payment than the client's wallet. In that case the wallet will not be able to prove the transaction to the server. Wallets should not rely on the transaction id of the outgoing transaction. Instead it should listen for the transaction on the network and put that in its list of transactions.
+* Transaction malleability may cause the server to have a different transaction id for a payment than the client's wallet. In that case the wallet will not be able to prove the transaction to the server. Wallets should not rely on the transaction id of the outgoing transaction. Instead it should listen for the transaction on the network and put that in its list of transactions.
 
 == Reference implementation ==