1 files changed, 12 insertions, 6 deletions
diff --git a/bip-0047.mediawiki b/bip-0047.mediawiki
index af801f9..dc1f588 100644
--- a/bip-0047.mediawiki
+++ b/bip-0047.mediawiki
@@ -1,7 +1,7 @@
 RECENT CHANGES:
+* (15 Feb 2021) Finalize specification
+* (28 Sep 2017) Adjust text to match test vectors
 * (19 Apr 2016) Define version 2 payment codes
-* (17 Apr 2016) Clarify usage of outpoints in notification transactions
-* (18 Dec 2015) Update explanations to resolve FAQs
 
 <pre>
   BIP: 47
@@ -10,11 +10,17 @@ RECENT CHANGES:
   Author: Justus Ranvier <justus@openbitcoinprivacyproject.org>
   Comments-Summary: Unanimously Discourage for implementation
   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0047
-  Status: Draft
+  Status: Final
   Type: Informational
   Created: 2015-04-24
 </pre>
 
+==Status==
+
+This BIP can be be considered final in terms of enabling compatibility with wallets that implement version 1 and version 2 reusable payment codes, however future developments of the reusable payment codes specification will not be distributed via the BIP process.
+
+The Open Bitcoin Privacy Project RFC repo should be consulted for specifications related to version 3 or higher payment codes: https://github.com/OpenBitcoinPrivacyProject/rfc
+
 ==Abstract==
 
 This BIP defines a technique for creating a payment code which can be publicly advertised and associated with a real-life identity without creating the loss of security or privacy inherent to P2PKH address reuse.
@@ -150,7 +156,7 @@ It is assumed that Alice can easily obtain Bob's payment code via a suitable met
 
 Prior to the first time Alice initiates a transaction to Bob, Alice MUST inform Bob of her payment code via the following procedure:
 
-Note: this procedure is used if Bob uses a version 1 payment code (regardless of the the version of Alice's payment code). If Bob's payment code is not version 1, see the appropriate section in this specification.
+Note: this procedure is used if Bob uses a version 1 payment code (regardless of the version of Alice's payment code). If Bob's payment code is not version 1, see the appropriate section in this specification.
 
 # Alice constructs a transaction which sends a small quantity of bitcoins to Bob's notification address (notification transaction)
 ## The inputs selected for this transaction MUST NOT be easily associated with Alice's notification address
@@ -158,7 +164,7 @@ Note: this procedure is used if Bob uses a version 1 payment code (regardless of
 ## Alice selects the private key corresponding to the designated pubkey: <pre>a</pre>
 ## Alice selects the public key associated with Bob's notification address: <pre>B, where B = bG</pre>
 ## Alice calculates a secret point: <pre>S = aB</pre>
-## Alice calculates a 64 byte blinding factor: <pre>s = HMAC-SHA512(x, o)</pre>
+## Alice calculates a 64 byte blinding factor: <pre>s = HMAC-SHA512(o, x)</pre>
 ### "x" is the x value of the secret point
 ### "o" is the outpoint being spent by the designated input
 # Alice serializes her payment code in binary form.
@@ -229,7 +235,7 @@ The following actions are recommended to reduce this risk:
 <img src="bip-0047/reusable_payment_codes-04.png" />
 <img src="bip-0047/reusable_payment_codes-05.png" />
 # Bob is watching for incoming payments on B' ever since he received the notification transaction from Alice.
-## Bob calculates n shared secrets with Alice, using the 0<sup>th</sup> public key derived Alice's payment code, and private keys 0 - n derived from Bob's payment code, where n is his desired lookahead window.
+## Bob calculates n shared secrets with Alice, using the 0<sup>th</sup> public key derived from Alice's payment code, and private keys 0 - n derived from Bob's payment code, where n is his desired lookahead window.
 ## Bob calculates the ephemeral deposit addresses using the same procedure as Alice: <pre>B' = B + sG</pre>
 ## Bob calculate the private key for each ephemeral address as: <pre>b' = b + s</pre>
 <img src="bip-0047/reusable_payment_codes-02.png" />