Add backwards compatibility section

1 files changed, 5 insertions, 1 deletions

diff --git a/bip-bustapay.mediawiki b/bip-bustapay.mediawiki
index 084aea1..7e4e591 100644
--- a/bip-bustapay.mediawiki
+++ b/bip-bustapay.mediawiki
@@ -67,7 +67,7 @@ The template transaction should be sent to the receiver via an HTTP POST to the
 
 The receiver is then responsible for validating the template transaction. If there is a problem with the transaction, or the receiver is generally unhappy with the transaction (e.g. fees are too small) the HTTP response code of 422 should be used and a human-readable string containing information on why which can be directly given to the user.
 
-Should the receiver reject a transaction, it should not attempt to propagate it on the network. However it is important for the send to be aware that the receiver *can* at any time until one of the inputs has been used and thus invalidates the transaction.
+Should the receiver reject a transaction, it should not attempt to propagate it on the network. However it is important for the sender to be aware that the receiver *could* at any time (regardless of which error was given) send this transaction. The client should therefor assume the receiver will, and act accordingly (either retry with adjustments or just propagate the transaction). It is imperative that the sender never finds themselves in a situation where two payments to the sender could be valid. 
 
 === Contributed Input Choice ===
 
@@ -115,6 +115,10 @@ For anyone wanting to implement bustapay payments, here are some notes for recei
 * A reference implementation is maintained at https://github.com/rhavar/bustapay which functions as a wrapper around some RPC calls to bitcoin core's wallet.
 * The sender must be careful of an attack where the receiver tries to add additional inputs that are controlled by the sender, with the hope that the sender blindly signs it.
 
+== Backwards Compatibility ==
+
+Bustapay is an optional payment protocol and therefor has no backwards compatibility concerns. It in fact can only be supported in addition to normal transaction processing, as falling back to a normal bitcoin transaction is a required behavior.
+
 
 == Credits ==
 The idea is obviously based upon Dr. Maxwell's seminal CoinJoin proposal, and reduced scope inspired by a simplification of the "pay 2 endpoint" blog post by blockstream.