Two potential third-party services

Author: clarkmoody

bip-alfredhodler-privatepayments.mediawiki

@@ -157,7 +157,7 @@ When Bob wants to spend from such addresses, he calculates his private keys in t
 
 ''p<sub>c</sub> = p + s''
 
-==Test Vectors==
+==Appendix A: Test Vectors==
 
 ===Alice's Wallet===
 
@@ -217,6 +217,16 @@ When Bob wants to spend from such addresses, he calculates his private keys in t
 
 '''p<sub>c</sub>:''' 0xf2f9c44c15a0b9f3590ab36e6324ab781b12e3f40abc745611d06a46894aab88
 
+==Appendix B: Potential OP_RUTURN Services==
+
+Compact Block Filters, as formulated in BIP-0158, do not cover <code>OP_RETURN</code> data payloads. In support of light wallets, an external service could publish transaction proofs for all transactions that include the tagged notification payload. Light wallets would download all such transactions, filter for matches against their payment code, then verify the transaction proofs against the block headers obtained over the P2P network.
+
+==Appendix C: Potential Notification Transaction Services==
+
+No specific instruction is given as to the details of the notification transaction beyond simply including the single <code>OP_RETURN</code> payload. Since no restriction exists for other inputs or outputs of this transaction, there is an opportunity for an external service to include this payload in a transaction completely unrelated to Alice's wallet. Such a service could charge a fee out-of-band to help cover fees.
+
+Another opportunity exists for an existing business to attach notification payloads to transactions sent during the normal course of operations. Large withdrawal transactions from mining pools or exchanges could include a marginal notification payload without affecting overall fees.
+
 ==Reference==
 * [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic Wallets]]
 * [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic Wallets]]