Updates to the BIP

- fix out of range indexing
- add a note about compressed keys
- add a note about of-of-band notifications
- add a backward compatibility section

bip-alfredhodler-privatepayments.mediawiki

@@ -80,7 +80,7 @@ m / purpose' / coin_type' / account'
 ===Payment Code Structure and Encoding===
 
 * bytes <code>[0..2]</code>: address type flags (2 bytes)
-* bytes <code>[2..36]</code>: compressed public key P (33 bytes)
+* bytes <code>[2..35]</code>: compressed public key P (33 bytes)
 
 Payment codes are encoded in bech32m and the human readable part is "pay" for mainnet and "payt" for testnet (all types), resulting in payment codes that look like "pay1cqqq8d29g0a7m8ghmycqk5yv24mfh3xg8ptzqcn8xz6d2tjl8ccdnfkpjl7p84".
 
@@ -104,6 +104,8 @@ The remaining flags are reserved for future address types.
 
 While payment codes use 2-byte bitflag arrays, notifications use ordinal values in the form of a single byte.
 
+All keys are compressed. Using uncompressed keys at any point is illegal.
+
 ===Notifications===
 
 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:
@@ -134,6 +136,8 @@ When Bob notices a 40-byte <code>OP_RETURN</code> starting with ''search key'',
 
 Since changing ''x'' yields a completely different sender identity, Alice can always re-notify Bob from a different index when she does not want to be associated with her previous identity. Alice can also re-notify Bob when she wants to start sending to a different address type. Bob must be able to update his watchlist in that case and he can stop watching addresses associated with the old address type.
 
+Out-of-band notifications between Alice and Bob are legal (in fact, they may not be prevented), but in that case Bob loses the ability to restore his wallet from <code>OP_RETURN</code> outputs embedded in the blockchain. In that case, Bob has the burden of keeping a valid backup of any out-of-band notifications.
+
 ===Allowing Notification Collisions===
 
 Since ''notification_code'' is a 4-byte truncation of the full value, Bob has a 1 in ~4.3 billion chance of detecting a spurious notification. This is considered acceptable because the cost of doing so is adding a few more addresses to Bob's watchlist. The benefit of this approach is that is saves 28 bytes per notification.
@@ -170,6 +174,12 @@ When Bob wants to spend from such addresses, he calculates his private keys in t
 
 ''p<sub>c</sub> = p + s''
 
+==Backward Compatibility==
+
+Private Payments is a new standard which is not compatible with any previous standard based on static payment codes, such as BIP47.
+
+While the standard does not support versioning, it reserves unused bits in the address type bitflag array which can be allocated to new address types once they are deemed ubiquitous. Older payment codes (i.e. those generated when fewer address types were available) are readable by software supporting new address types. The reverse is also supported since older software will ignore newer address type flags that are not understood.
+
 ==Appendix A: Test Vectors==
 
 ===Alice's Wallet===