chore(bip-0046): fix typos and grammar

1 files changed, 6 insertions, 6 deletions

diff --git a/bip-0046.mediawiki b/bip-0046.mediawiki
index b5088fc..e456604 100644
--- a/bip-0046.mediawiki
+++ b/bip-0046.mediawiki
@@ -23,7 +23,7 @@ It would be useful to have a common derivation scheme so that users of wallet so
 
 We largely use the same approach used in BIPs 49, 84 and 86 for ease of implementation.
 
-This standard is already implemented and deployed in JoinMarket. As most changes would requires a protocol change of a live system, there is limited scope for changing this standard in review. This BIP is more about documenting something which already exists, warts and all.
+This standard is already implemented and deployed in JoinMarket. As most changes would require a protocol change of a live system, there is limited scope for changing this standard in review. This BIP is more about documenting something which already exists, warts and all.
 
 It would be useful to be able to keep the private keys of fidelity bonds in cold storage. This would allow the sybil resistance of a system to increase without hot wallet risk.
 
@@ -52,7 +52,7 @@ It would be useful for the user to avoid having to keep a record of the timelock
 
 == Specifications ==
 
-This BIP defines the two needed steps to derive multiple deterministic addresses based on a [[bip-0032.mediawiki|BIP 32]] master private key. It also defines the format of the certificate can be signed by the deterministic address key.
+This BIP defines the two needed steps to derive multiple deterministic addresses based on a [[bip-0032.mediawiki|BIP 32]] master private key. It also defines the format of the certificate that can be signed by the deterministic address key.
 
 === Public key derivation ===
 
@@ -79,9 +79,9 @@ month = 1 + index % 12
 
 === Address derivation ===
 
-To derive the address from the above calculated public key and timelock, we create a <tt>redeemScript</tt> which locks the funds until the <tt>timelock</tt>, and then checks the signature of the <tt>derived_key</tt>. The <tt>redeemScript</tt> is hashed with SHA256 to produce a 32-byte hash value that forms the <tt>scriptPubKey</tt> of the P2WSH address.
+To derive the address from the above calculated public key and timelock, we create a <tt>witness script</tt> which locks the funds until the <tt>timelock</tt>, and then checks the signature of the <tt>derived_key</tt>. The <tt>witness script</tt> is hashed with SHA256 to produce a 32-byte hash value that forms the <tt>scriptPubKey</tt> of the P2WSH address.
 
-    redeemScript: <timelock> OP_CHECKLOCKTIMEVERIFY OP_DROP <derived_key> OP_CHECKSIG
+    witnessScript: <timelock> OP_CHECKLOCKTIMEVERIFY OP_DROP <derived_key> OP_CHECKSIG
     witness:      <signature> <pubkey>
     scriptSig:    (empty)
     scriptPubKey: 0 <32-byte-hash>
@@ -89,11 +89,11 @@ To derive the address from the above calculated public key and timelock, we crea
 
 === Message signing ===
 
-In order to support signing of certificates, implementors should support signing ascii messages.
+In order to support signing of certificates, implementors should support signing ASCII messages.
 
 A certificate message can be created by another application external to this standard. It is then prepended with the string `\x18Bitcoin Signed Message:\n` and a byte denoting the length of the certificate message. The whole thing is then signed with the private key of the <tt>derived_key</tt>. This part is identical to the "Sign Message" function which many wallets already implement.
 
-Almost all wallets implementing this standard can use their already-existing "Sign Message" function to sign the certificate message. As the certificate message itself is always an ascii string, the wallet may not need to specially implement this section at all but just rely on users copypasting their certificate message into the already-existing "Sign Message" user interface. This works as long as the wallet knows how to use the private key of the timelocked address for signing messages.
+Almost all wallets implementing this standard can use their already-existing "Sign Message" function to sign the certificate message. As the certificate message itself is always an ASCII string, the wallet may not need to specially implement this section at all but just rely on users copypasting their certificate message into the already-existing "Sign Message" user interface. This works as long as the wallet knows how to use the private key of the timelocked address for signing messages.
 
 It is most important for wallet implementions of this standard to support creating the certificate signature. Verifying the certificate signature is less important.