Renamed to BIP75, added extensions to BIP70 payment details

bip-0070/extensions.mediawiki

@@ -3,7 +3,9 @@
 Add your extension below using tags starting at 1000 and submit a pull-req.
 
 {|
-| Field Number || Extension Name || Field Name || Description
+| Field Number || Extension Name || Field Name || Payment Details Version || Description
 |-
-| 1000 || [[https://example.com|(unassigned)]] || (unassigned) || (unassigned)
+| 1000 || [[https://github.com/bitcoin/bips/blob/master/bip-0075.mediawiki|BIP0075]] || subtract_fee || 1 || If "true," indicates the sender can subtract the transaction fee from the requested amount. Otherwise, the transaction fee must be included separately from the requested amount.
+|-
+| 1001 || [[https://github.com/bitcoin/bips/blob/master/bip-0075.mediawiki|BIP0075]] || replace_by_fee || 2 || If "true," indicates the sender can enable the Replace By Fee flag for this transaction and the receiver will still consider it accepted with zero confirmations. Otherwise, RBF transactions will not be accepted by the receiver until they are confirmed.
 |}

bip-0075.mediawiki

@@ -1,5 +1,5 @@
 <pre>
-  BIP:     TBD
+  BIP:     75
   Title:   Out of Band Address Exchange using Encrypted PaymentRequests
   Authors: Justin Newton <justin@netki.com>
            Matt David <mgd@mgddev.com>
@@ -82,7 +82,7 @@ service. In this case, a successful attack against a Store & Forward service wou
 or payment information, only delete encrypted messages.
 
 ==New Messages==
-Updated [/bip-ir/paymentrequest.proto paymentrequest.proto] contains the existing PaymentRequest Protocol Buffer messages as well as
+Updated [/bip-0075/paymentrequest.proto paymentrequest.proto] contains the existing PaymentRequest Protocol Buffer messages as well as
 the messages newly defined in this BIP.
 
 Note: Public keys from both parties must be known to each other in order to facilitate encrypted communication. Although including both public keys in every message may get redundant, it provides the most flexibility as each message is completely self-contained.
@@ -273,7 +273,7 @@ Optionally, the Sender MAY choose to encrypt the InvoiceRequest message and ther
 # The PaymentRequest is processed according to BIP70, including optional Payment and PaymentACK messages
 
 
-<img src="bip-ir/invoice-request-process.png"></img>
+<img src="bip-0075/invoice-request-process.png"></img>
 
 ===Encrypted InvoiceRequest Overview===
 # Sender retrieves Receiver InvoiceRequest Public Key
@@ -293,7 +293,7 @@ Optionally, the Sender MAY choose to encrypt the InvoiceRequest message and ther
 
 <b>NOTE:</b> See section <b>Initial Public Key Retrieval for InvoiceRequest Encryption</b> below for possible options to retrieve Receiver InvoiceRequest public keys.
 
-<img src="bip-ir/encrypted-invoice-request-process.png"></img>
+<img src="bip-0075/encrypted-invoice-request-process.png"></img>
 
 ==Message Interaction Details==
 
@@ -437,7 +437,7 @@ A reference client implementation can be found in the InvoiceRequest functional
 ==BIP70 Extension==
 The following flowchart is borrowed from BIP70 and expanded upon in order to visually describe how this BIP is an extension to BIP70.
 
-<img src="bip-ir/bip70-extension.png"></img>
+<img src="bip-0075/bip70-extension.png"></img>
 
 ==Mobile to Mobile Examples==
 
@@ -446,21 +446,56 @@ The following diagram shows a sample flow in which one mobile client is sending
 of an InvoiceRequest, a Store & Forward server, an EncryptedPaymentRequest (with require_payment_message = true), an 
 EncryptedPayment and an EncryptedPaymentACK. In this case, the Receiver submits the transaction to the bitcoin network.
 
-<img src="bip-ir/mobile-sf-ir-with-payment.png"></img>
+<img src="bip-0075/mobile-sf-ir-with-payment.png"></img>
 
 ===EncryptedPayment NOT Required===
 The following diagram shows a sample flow in which one mobile client is sending value to a second mobile client with the use
 of an InvoiceRequest, a Store & Forward server, and an EncryptedPaymentRequest (with require_payment_message = false). 
 In this case, the Sender submits the transaction to the bitcoin network.
 
-<img src="bip-ir/mobile-sf-ir-without-payment.png"></img>
+<img src="bip-0075/mobile-sf-ir-without-payment.png"></img>
 
 ===Using EncryptedInvoiceRequest Message===
 The following diagram shows a sample flow in which one mobile client is sending value to a second mobile client with the use
 of an EncryptedInvoiceRequest, a Store & Forward server, and an EncryptedPaymentRequest (with require_payment_message = false). 
 In this case, the Sender submits the transaction to the bitcoin network.
 
-<img src="bip-ir/mobile-sf-encrypted-ir-without-payment.png"></img>
+<img src="bip-0075/mobile-sf-encrypted-ir-without-payment.png"></img>
+
+==Extending BIP70 PaymentDetails==
+
+To keep up with recent advancements in transaction type, two optional fields will be added to the BIP 70 PaymentDetails message. subtract_fee will be added to the current version 1 fields, making the complete list look like the following:
+
+
+<pre>
+    message PaymentDetails {
+        optional string network [default = "main"];
+        repeated Output outputs;
+        required uint64 time;
+        optional uint64 expires;
+        optional string memo;
+        optional string payment_url;
+        optional bytes merchant_data;
+        optional bool subtract_fee = 1;
+    }
+</pre>
+
+replace_by_fee will be added as a version 2 field, meaning it is only available if payment_details_version is set to 2 or higher in the PaymentRequest message:
+
+<pre>
+    message PaymentDetails {
+        ...
+        optional bool replace_by_fee = 2;
+    }
+</pre>
+
+{| class="wikitable"
+! Field Name !! Field Number || Payment Details Version !! Description
+|-
+| subtract_fee                      ||  1000   || 1 || If "true," indicates the sender can subtract the transaction fee from the requested amount. Otherwise, the transaction fee must be included separately from the requested amount.
+|-
+| replace_by_fee                    ||  1001   || 2 || If "true," indicates the sender can enable the Replace By Fee flag for this transaction and the receiver will still consider it accepted with zero confirmations. Otherwise, RBF transactions will not be accepted by the receiver until they are confirmed.
+|}
 
 ==References==