From 50e707bd8c6ed36f36ea3c8447f043dee5c2a0f9 Mon Sep 17 00:00:00 2001
From: Alfred Hodler <100861939+alfred-hodler@users.noreply.github.com>
Date: Mon, 1 Aug 2022 12:15:46 +0000
Subject: [PATCH] Leaner notifications

---
 bip-alfredhodler-privatepayments.mediawiki | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/bip-alfredhodler-privatepayments.mediawiki b/bip-alfredhodler-privatepayments.mediawiki
index aef0d80c..159d4274 100644
--- a/bip-alfredhodler-privatepayments.mediawiki
+++ b/bip-alfredhodler-privatepayments.mediawiki
@@ -106,11 +106,11 @@ While payment codes use 2-byte bitflag arrays, notifications use ordinal values
 
 ===Notifications===
 
-Notifications are performed by publishing transactions that contain a 44-byte <code>OP_RETURN</code> output. The value of the <code>OP_RETURN</code> is constructed using the following formula:
+Notifications are performed by publishing transactions that contain a 40-byte <code>OP_RETURN</code> output. The value of the <code>OP_RETURN</code> is constructed using the following formula:
 
 ''search_key | notification_code | N<sub>x</sub> | address_type''
 
-* ''search_key'' equals "BIP999" and is a static ASCII-encoded string (6 bytes)
+* ''search_key'' equals "PP" and is a static ASCII-encoded string (2 bytes)
 * ''notification_code'' is ''H(n<sub>x</sub> * P)[0..4]'' (4 bytes)
 * ''N<sub>x</sub>'' is the unique public key a sender is using for a particular recipient (33 bytes)
 * ''address_type'' is the '''ordinal''' value of a single address type that a sender wants to send to (1 byte). This must be selected from the recepient's accepted address types.
@@ -124,7 +124,7 @@ When Alice wants to notify Bob that he will receive future payments from her, sh
 # Selects any UTXO in her wallet, preferably not associated with her.
 # Sends a transaction including an <code>OP_RETURN</code> output whose value is set to the constructed payload.
 
-When Bob notices an <code>OP_RETURN</code> starting with the search key, he performs the following procedure:
+When Bob notices a 40-byte <code>OP_RETURN</code> starting with ''search key'', he performs the following procedure:
 
 # Breaks down the payload into its four constituent parts.
 # Discards the ''search_key'' (item #0).
@@ -142,6 +142,8 @@ Since ''notification_code'' is a 4-byte truncation of the full value, Bob has a
 
 There is a scanning requirement on the recipient side in that the recipient must have access to full blocks in order to be able to search them for OP_RETURN outputs containing notifications. For more information on how light clients can get around this limitation and still use the standard, see Appendix B.
 
+Recipients that do not want to decode raw block data can quickly search for notifications in a block by looking for the following byte array: <code>[106, 40, 80, 80]</code>. The first two bytes represent ''OP_RETURN'' and ''OP_PUSHBYTES_40'', followed by the ASCII value of ''search_key''.
+
 ===Transacting===
 
 Alice initializes counter ''c'' which is unique to Bob and increments with each transaction. ''c'' is a 64-bit integer and must be inputted into a hasher as a big-endian encoded array of 8 bytes.
@@ -208,7 +210,7 @@ When Bob wants to spend from such addresses, he calculates his private keys in t
 
 '''Address type commitment:''' 1 (segwit)
 
-'''Notification output script:''' OP_RETURN OP_PUSHBYTES_44 424950393939fbe8d683039d138aaf5bc2e27a9740541576eceb90a5f20b4799dbfda48e5c7ca24050575301
+'''Notification output script:''' OP_RETURN OP_PUSHBYTES_40 5050fbe8d683039d138aaf5bc2e27a9740541576eceb90a5f20b4799dbfda48e5c7ca24050575301
 
 
 ===Alice sending to Bob===