From fd249cb305cf89bee23ba1a76e01b56fa3e37a24 Mon Sep 17 00:00:00 2001
From: Matt David <matt@netki.com>
Date: Fri, 10 Jun 2016 09:47:06 -0700
Subject: [PATCH 01/13] Initial Commit of http-address-service BIP draft

---
 bip-http-address-service.mediawiki | 125 +++++++++++++++++++++++++++++
 1 file changed, 125 insertions(+)
 create mode 100644 bip-http-address-service.mediawiki

diff --git a/bip-http-address-service.mediawiki b/bip-http-address-service.mediawiki
new file mode 100644
index 00000000..045d75db
--- /dev/null
+++ b/bip-http-address-service.mediawiki
@@ -0,0 +1,125 @@
+<pre>
+  BIP: XXX
+  Title: Endpoint Capability Discovering using HTTP Address Service
+  Author: Justin Newton <justin@netki.com>
+          Matt David <mgd@mgddev.com>
+  Status: Draft
+  Type: Standards Track
+  Created: 2016-06-10
+</pre>
+
+==Abstract==
+
+The proposed TLS-protected HTTP Address Service BIP aims to define a common flow for interacting with a TLS-protected HTTP Address Service such that Address Services can be provided to the client. Address Services may provide any of the following:
+
+# Wallet address
+# BitcoinURI
+# PaymentRequest
+# Store & Forward Services (supporting the Payment Protocol)
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 
+"OPTIONAL" in this document are to be interpreted as described in RFC 2119.
+
+==Motivation==
+
+As the use of bitcoin, as well as other blockchain-based currencies, digital assets, and payment networks continues to expand, the issue of address exchange becomes ever more important. With the introduction of safer, more secure, and user friendly address exchange processes such as [[bip-0075.mediawiki|BIP75]], there comes the issue of how to expose addresses. In order to negotiate for the most secure supported method of address exchange, we feel the best way is through a unique endpoint. This will serve HD wallet addresses and [[bip-0070.mediawiki|BIP70]] PaymentRequests as well as accept [[bip-0075.mediawiki|BIP75]] InvoiceRequests through a unique endpoint that can specifically expose supported methods via negotiation between the two parties. This specification proposes a standard HTTP flow for service discovery, wallet address retrieval (plaintext, BitcoinURI and PaymentRequest) as well as [[bip-0075.mediawiki|BIP75]] message passing.
+
+==Use Cases==
+
+===HD Wallet Address Exchange / BIP70 Endpoint===
+
+A bitcoin wallet developer would like to dynamically retrieve a unique address for a remote wallet. The developer would prefer a PaymentRequest, but would accept a BitcoinURI ([[bip-0021.mediawiki|BIP21]]). The Address Service spec allows the developer to discover which address options are available, if any. The developer can then specify which type of data they would prefer (based on availability) and submit a request for that data.
+
+===BIP75 InvoiceRequest Submission Endpoint===
+
+A bitcoin wallet developer would like to use [[bip-0075.mediawiki|BIP75]] to get a fully validated address. The Address Service specification allows the developer to discover if the receiving wallet (via the address endpoint) supports [[bip-0075.mediawiki|BIP75]]. Additionally, the Address Service specification provides the URI where a [[bip-0075.mediawiki|BIP75]] InvoiceRequest may be submitted if supported.
+
+==Details==
+
+===DANE / TLSA===
+
+Address Servers SHOULD be DANE / TLSA (RFC 7671) enabled. 
+
+===Available Services===
+
+This flow will use a HTTP OPTIONS request to the address endpoint URL in order to determine service availability. The response will use the '''Allow''' (existing) and '''Accept''' (existing) HTTP headers to inform the client which services the address endpoint supports.
+ 
+====Allow Header Usage====
+
+The '''Allow''' header is used, as defined in RFC 2616 (14.7), to supply the client with supported HTTP methods for use with the address endpoint URL. The '''Allow''' header must return supported HTTP methods for the available return MIME types. See the table below for HTTP methods that relate to supported return MIME types.
+
+====Accept Header Usage====
+
+The '''Accept''' header is defined in RFC 2616 (14.1) and is used in the OPTIONS response. This header is generally used in the client request, but this specification uses it in the Address Service OPTIONS response.
+
+The '''Accept''' header MUST contain all acceptable MIME types for the endpoint. The following table defines MIME types for the appropriate return values:
+
+{| class="wikitable"
+! MIME Type !! HTTP Method !! HTTP Response Content
+|- 
+| text/plain                                                || GET  || Raw Wallet Address
+|-
+| application/bitcoin-uri                                   || GET  || Bitcoin URL ([[bip-0021.mediawiki|BIP21]] / [[bip-0072.mediawiki|BIP72]])
+|-
+| application/bitcoin-paymentrequest                        || GET  || [[bip-0070.mediawiki|BIP70]] PaymentRequest
+|-
+| application/bitcoin-paymentprotocol-message               || POST || [[bip-0075.mediawiki|BIP75]] ProtocolMessage 
+|-
+| application/bitcoin-encrypted-paymentprotocol-message     || POST || [[bip-0075.mediawiki|BIP75]] EncryptedProtocolMessage
+|-
+|}
+
+Based on the '''Allow''' and '''Accept''' headers in the OPTIONS response, the client MAY make another TLS-protected HTTP call to the URL using the HTTP method for the data type and the '''Accept''' value that the client requests.
+
+====Optional Public Key Sharing====
+
+In order to fully support [[bip-0075.mediawiki|BIP75]] Payment Protocol using EncryptedProtocolMessages, the Address Service MAY provide a '''receiver_public_key''' for the address endpoint by including the '''X-Identity''' HTTP header in the response. The contents of the '''X-Identity''' header MUST be a hex-encoded, DER-formatted EC Public Key.
+
+===Raw Wallet Addresses, BitcoinURIs and PaymentRequests===
+
+====Request====
+
+A HTTP GET request on a TLS-protected HTTP address endpoint MUST set the '''Accept''' header to the requested content type. This requested content type MUST have been listed in the '''Accept''' header of the previous OPTIONS response. 
+
+====Response====
+
+The Address Service MUST respond with the appropriate requested data type and a HTTP Status Code of 200 (OK). 
+
+If the data type is temporarily unavailable and should be retried later, the Address Service MUST respond with a HTTP Status Code of 503 (Service Unavailable). The Address Service MAY include a '''Retry-After''' HTTP Header if it can determine when an appropriate response will be available.
+
+If the data type is permanently unavailable, for example if the address endpoint has been disabled, the Address Service MUST respond with a HTTP Status Code of 410 (Gone).
+
+===Handling BIP75 Messages===
+
+====Request====
+
+A HTTP POST request on a TLS-protected HTTP address endpoint MUST set the '''Accept''' header to the requested response MIME Type. The available response MIME Types for this request are:
+
+application/bitcoin-paymentprotocol-message
+application/bitcoin-encrypted-paymentprotocol-message
+
+The HTTP POST request MUST set the '''Content-Transfer-Encoding''' header to "binary" and the '''Content-Type header''' to either of the aforementioned MIME Types. The content of the POST message MUST be the binary representation of a serialized ProtocolMessage or EncryptedProtocolMessage.
+
+====Immediate Response (200)====
+
+The Address Service MUST respond with a HTTP Status Code of 200 (OK) if the response type is a ProtocolMessage or EncryptedProtocolMessage. The Address Service MUST respond with a ProtocolMessage or EncryptedProtocolMessage based on the '''Accept''' header in the client request.
+ 
+====Delayed Response (202)====
+
+The Address Service MUST respond with a HTTP Status Code of 202 (Accepted) and the '''Location''' header set to a location to later retrieve the resulting ProtocolMessage or EncryptedProtocolMessage
+
+'''NOTE''': [[bip-0075.mediawiki|BIP75]] messages SHOULD be transmitted using EncryptedProtocolMessage message types in order to provide additional application-layer security.
+
+
+==Implementation==
+
+TBD
+
+==References==
+* [[bip-0021.mediawiki|BIP21 - URI Scheme]]
+* [[bip-0070.mediawiki|BIP70 - Payment Protocol]]
+* [[bip-0072.mediawiki|BIP72 - bitcoin: URI Extensions for Payment Protocol]]
+* [[bip-0075.mediawiki|BIP75 - Out of Band Address Exchange using Payment Protocol Encryption]]
+* [https://tools.ietf.org/html/rfc2616 RFC2616 - Hypertext Transfer Protocol -- HTTP/1.1]
+* [https://tools.ietf.org/html/rfc6698 RFC6698 - The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA]
+* [https://tools.ietf.org/html/rfc7671 RFC7671 - The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance]
\ No newline at end of file

From 8905c7436d589671c122662670fe841ed489726b Mon Sep 17 00:00:00 2001
From: Matt David <matt@netki.com>
Date: Fri, 10 Jun 2016 09:48:53 -0700
Subject: [PATCH 02/13] Cleanup Response titles and bold HTTP response codes

---
 bip-http-address-service.mediawiki | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/bip-http-address-service.mediawiki b/bip-http-address-service.mediawiki
index 045d75db..d45ae3b5 100644
--- a/bip-http-address-service.mediawiki
+++ b/bip-http-address-service.mediawiki
@@ -83,7 +83,7 @@ A HTTP GET request on a TLS-protected HTTP address endpoint MUST set the '''Acce
 
 ====Response====
 
-The Address Service MUST respond with the appropriate requested data type and a HTTP Status Code of 200 (OK). 
+The Address Service MUST respond with the appropriate requested data type and a HTTP Status Code of '''200 (OK)'''. 
 
 If the data type is temporarily unavailable and should be retried later, the Address Service MUST respond with a HTTP Status Code of 503 (Service Unavailable). The Address Service MAY include a '''Retry-After''' HTTP Header if it can determine when an appropriate response will be available.
 
@@ -100,13 +100,13 @@ application/bitcoin-encrypted-paymentprotocol-message
 
 The HTTP POST request MUST set the '''Content-Transfer-Encoding''' header to "binary" and the '''Content-Type header''' to either of the aforementioned MIME Types. The content of the POST message MUST be the binary representation of a serialized ProtocolMessage or EncryptedProtocolMessage.
 
-====Immediate Response (200)====
+====Immediate Response====
 
-The Address Service MUST respond with a HTTP Status Code of 200 (OK) if the response type is a ProtocolMessage or EncryptedProtocolMessage. The Address Service MUST respond with a ProtocolMessage or EncryptedProtocolMessage based on the '''Accept''' header in the client request.
+The Address Service MUST respond with a HTTP Status Code of '''200 (OK)''' if the response type is a ProtocolMessage or EncryptedProtocolMessage. The Address Service MUST respond with a ProtocolMessage or EncryptedProtocolMessage based on the '''Accept''' header in the client request.
  
-====Delayed Response (202)====
+====Delayed Response====
 
-The Address Service MUST respond with a HTTP Status Code of 202 (Accepted) and the '''Location''' header set to a location to later retrieve the resulting ProtocolMessage or EncryptedProtocolMessage
+The Address Service MUST respond with a HTTP Status Code of '''202 (Accepted)''' and the '''Location''' header set to a location to later retrieve the resulting ProtocolMessage or EncryptedProtocolMessage
 
 '''NOTE''': [[bip-0075.mediawiki|BIP75]] messages SHOULD be transmitted using EncryptedProtocolMessage message types in order to provide additional application-layer security.
 

From a62ba93990e3bd5f7fc1bd33e256ffc116ebf49d Mon Sep 17 00:00:00 2001
From: Matt David <matt@netki.com>
Date: Fri, 10 Jun 2016 09:50:39 -0700
Subject: [PATCH 03/13] Add links for RFCs

---
 bip-http-address-service.mediawiki | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/bip-http-address-service.mediawiki b/bip-http-address-service.mediawiki
index d45ae3b5..52df7ba8 100644
--- a/bip-http-address-service.mediawiki
+++ b/bip-http-address-service.mediawiki
@@ -38,7 +38,7 @@ A bitcoin wallet developer would like to use [[bip-0075.mediawiki|BIP75]] to get
 
 ===DANE / TLSA===
 
-Address Servers SHOULD be DANE / TLSA (RFC 7671) enabled. 
+Address Servers SHOULD be DANE / TLSA ([https://tools.ietf.org/html/rfc7671 RFC 7671]) enabled. 
 
 ===Available Services===
 
@@ -46,11 +46,11 @@ This flow will use a HTTP OPTIONS request to the address endpoint URL in order t
  
 ====Allow Header Usage====
 
-The '''Allow''' header is used, as defined in RFC 2616 (14.7), to supply the client with supported HTTP methods for use with the address endpoint URL. The '''Allow''' header must return supported HTTP methods for the available return MIME types. See the table below for HTTP methods that relate to supported return MIME types.
+The '''Allow''' header is used, as defined in [https://tools.ietf.org/html/rfc2616 RFC2616 RFC 2616] (14.7), to supply the client with supported HTTP methods for use with the address endpoint URL. The '''Allow''' header must return supported HTTP methods for the available return MIME types. See the table below for HTTP methods that relate to supported return MIME types.
 
 ====Accept Header Usage====
 
-The '''Accept''' header is defined in RFC 2616 (14.1) and is used in the OPTIONS response. This header is generally used in the client request, but this specification uses it in the Address Service OPTIONS response.
+The '''Accept''' header is defined in [[https://tools.ietf.org/html/rfc2616 RFC 2616] (14.1) and is used in the OPTIONS response. This header is generally used in the client request, but this specification uses it in the Address Service OPTIONS response.
 
 The '''Accept''' header MUST contain all acceptable MIME types for the endpoint. The following table defines MIME types for the appropriate return values:
 

From 61674ca008b6f6030967971f07abb75859536951 Mon Sep 17 00:00:00 2001
From: Matt David <matt@netki.com>
Date: Fri, 10 Jun 2016 09:51:29 -0700
Subject: [PATCH 04/13] Add links for RFCs

---
 bip-http-address-service.mediawiki | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bip-http-address-service.mediawiki b/bip-http-address-service.mediawiki
index 52df7ba8..ac00e08d 100644
--- a/bip-http-address-service.mediawiki
+++ b/bip-http-address-service.mediawiki
@@ -46,11 +46,11 @@ This flow will use a HTTP OPTIONS request to the address endpoint URL in order t
  
 ====Allow Header Usage====
 
-The '''Allow''' header is used, as defined in [https://tools.ietf.org/html/rfc2616 RFC2616 RFC 2616] (14.7), to supply the client with supported HTTP methods for use with the address endpoint URL. The '''Allow''' header must return supported HTTP methods for the available return MIME types. See the table below for HTTP methods that relate to supported return MIME types.
+The '''Allow''' header is used, as defined in [https://tools.ietf.org/html/rfc2616 RFC 2616] (14.7), to supply the client with supported HTTP methods for use with the address endpoint URL. The '''Allow''' header must return supported HTTP methods for the available return MIME types. See the table below for HTTP methods that relate to supported return MIME types.
 
 ====Accept Header Usage====
 
-The '''Accept''' header is defined in [[https://tools.ietf.org/html/rfc2616 RFC 2616] (14.1) and is used in the OPTIONS response. This header is generally used in the client request, but this specification uses it in the Address Service OPTIONS response.
+The '''Accept''' header is defined in [https://tools.ietf.org/html/rfc2616 RFC 2616] (14.1) and is used in the OPTIONS response. This header is generally used in the client request, but this specification uses it in the Address Service OPTIONS response.
 
 The '''Accept''' header MUST contain all acceptable MIME types for the endpoint. The following table defines MIME types for the appropriate return values:
 

From faec02cd9782994e7b512859b919b97acb8334e3 Mon Sep 17 00:00:00 2001
From: Matt David <matt@netki.com>
Date: Fri, 10 Jun 2016 12:49:03 -0700
Subject: [PATCH 05/13] Removing Justin and adding Frank as co-author

---
 bip-http-address-service.mediawiki | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bip-http-address-service.mediawiki b/bip-http-address-service.mediawiki
index ac00e08d..2701dfd2 100644
--- a/bip-http-address-service.mediawiki
+++ b/bip-http-address-service.mediawiki
@@ -1,8 +1,8 @@
 <pre>
   BIP: XXX
   Title: Endpoint Capability Discovering using HTTP Address Service
-  Author: Justin Newton <justin@netki.com>
-          Matt David <mgd@mgddev.com>
+  Author: Matt David <mgd@mgddev.com>
+          Frank Contreras <frank@frankintosh.net>
   Status: Draft
   Type: Standards Track
   Created: 2016-06-10

From 3e89e8b9473a1621710b314b77b4d5864cecc51f Mon Sep 17 00:00:00 2001
From: Matt David <matt@netki.com>
Date: Fri, 10 Jun 2016 13:58:02 -0700
Subject: [PATCH 06/13] Remove whitespace causing empty grey boxes

---
 bip-http-address-service.mediawiki | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bip-http-address-service.mediawiki b/bip-http-address-service.mediawiki
index 2701dfd2..0c61a73e 100644
--- a/bip-http-address-service.mediawiki
+++ b/bip-http-address-service.mediawiki
@@ -43,7 +43,7 @@ Address Servers SHOULD be DANE / TLSA ([https://tools.ietf.org/html/rfc7671 RFC
 ===Available Services===
 
 This flow will use a HTTP OPTIONS request to the address endpoint URL in order to determine service availability. The response will use the '''Allow''' (existing) and '''Accept''' (existing) HTTP headers to inform the client which services the address endpoint supports.
- 
+
 ====Allow Header Usage====
 
 The '''Allow''' header is used, as defined in [https://tools.ietf.org/html/rfc2616 RFC 2616] (14.7), to supply the client with supported HTTP methods for use with the address endpoint URL. The '''Allow''' header must return supported HTTP methods for the available return MIME types. See the table below for HTTP methods that relate to supported return MIME types.
@@ -103,7 +103,7 @@ The HTTP POST request MUST set the '''Content-Transfer-Encoding''' header to "bi
 ====Immediate Response====
 
 The Address Service MUST respond with a HTTP Status Code of '''200 (OK)''' if the response type is a ProtocolMessage or EncryptedProtocolMessage. The Address Service MUST respond with a ProtocolMessage or EncryptedProtocolMessage based on the '''Accept''' header in the client request.
- 
+
 ====Delayed Response====
 
 The Address Service MUST respond with a HTTP Status Code of '''202 (Accepted)''' and the '''Location''' header set to a location to later retrieve the resulting ProtocolMessage or EncryptedProtocolMessage

From 73b2e134d1eb625db2102716e1ba6a6de2d62d2b Mon Sep 17 00:00:00 2001
From: Matt David <matt@netki.com>
Date: Fri, 10 Jun 2016 15:08:19 -0700
Subject: [PATCH 07/13] - Fix bulleting for mimetypes

---
 bip-http-address-service.mediawiki | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bip-http-address-service.mediawiki b/bip-http-address-service.mediawiki
index 0c61a73e..c6931e37 100644
--- a/bip-http-address-service.mediawiki
+++ b/bip-http-address-service.mediawiki
@@ -95,8 +95,8 @@ If the data type is permanently unavailable, for example if the address endpoint
 
 A HTTP POST request on a TLS-protected HTTP address endpoint MUST set the '''Accept''' header to the requested response MIME Type. The available response MIME Types for this request are:
 
-application/bitcoin-paymentprotocol-message
-application/bitcoin-encrypted-paymentprotocol-message
+* application/bitcoin-paymentprotocol-message
+* application/bitcoin-encrypted-paymentprotocol-message
 
 The HTTP POST request MUST set the '''Content-Transfer-Encoding''' header to "binary" and the '''Content-Type header''' to either of the aforementioned MIME Types. The content of the POST message MUST be the binary representation of a serialized ProtocolMessage or EncryptedProtocolMessage.
 

From 66e2d91754a5d387154639ca00fe801fb6e39bf9 Mon Sep 17 00:00:00 2001
From: Matt David <matt@netki.com>
Date: Fri, 10 Jun 2016 15:09:31 -0700
Subject: [PATCH 08/13] - Removing bolding on next word "header"

---
 bip-http-address-service.mediawiki | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bip-http-address-service.mediawiki b/bip-http-address-service.mediawiki
index c6931e37..bbb59217 100644
--- a/bip-http-address-service.mediawiki
+++ b/bip-http-address-service.mediawiki
@@ -98,7 +98,7 @@ A HTTP POST request on a TLS-protected HTTP address endpoint MUST set the '''Acc
 * application/bitcoin-paymentprotocol-message
 * application/bitcoin-encrypted-paymentprotocol-message
 
-The HTTP POST request MUST set the '''Content-Transfer-Encoding''' header to "binary" and the '''Content-Type header''' to either of the aforementioned MIME Types. The content of the POST message MUST be the binary representation of a serialized ProtocolMessage or EncryptedProtocolMessage.
+The HTTP POST request MUST set the '''Content-Transfer-Encoding''' header to "binary" and the '''Content-Type''' header to either of the aforementioned MIME Types. The content of the POST message MUST be the binary representation of a serialized ProtocolMessage or EncryptedProtocolMessage.
 
 ====Immediate Response====
 

From f7e08aa1a7979cc97d4d45f9ca5d98fd6467291e Mon Sep 17 00:00:00 2001
From: Matt David <matt@netki.com>
Date: Thu, 28 Jul 2016 09:26:36 -0700
Subject: [PATCH 09/13] - Add UNKNOWN_TYPE to ProtocolMessageType enum in
 paymentrequest.proto and BIP75 text (based on suggestions from
 http://androiddevblog.com/protocol-buffers-pitfall-adding-enum-values/) -
 Update BIP75 Motivation and use cases to provide more color around reasoning
 and use of BIP75

NOTE: The BIP75 language no longer contains a description of the KYC compliance use case, as it is a single, very specific use-case that does not have any bearing on the technical specifications herein. BIP75 extends the original BIP70 Payment Protocol to become a two-way, encrypted messaging process, which can be used for a variety of reasons one of which is regulatory compliance.
---
 bip-0075.mediawiki            | 24 ++++++++++++------------
 bip-0075/paymentrequest.proto |  9 +++++----
 2 files changed, 17 insertions(+), 16 deletions(-)

diff --git a/bip-0075.mediawiki b/bip-0075.mediawiki
index 9ce90f6d..45ae282e 100644
--- a/bip-0075.mediawiki
+++ b/bip-0075.mediawiki
@@ -30,7 +30,7 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S
 
 ==Motivation==
 
-The motivation for defining this extension to the [[bip-0070.mediawiki|BIP70]] Payment Protocol is to allow 2 parties to exchange payment information in a permissioned and encrypted way such that wallet address communication can become a more automated process. Additionally, this extension allows for the requester of a PaymentRequest to supply a certificate and signature in order to facilitate identification for address release. This also allows for automated creation of off blockchain transaction logs that are human readable, containing who you transacted with, in addition to the information that it contains today.
+The motivation for defining this extension to the [[bip-0070.mediawiki|BIP70]] Payment Protocol is to allow two parties to exchange payment information in a permissioned and encrypted way, such that wallet address communication can become a more automated process. This extension also expands the types of PKI (public-key infrastructure) data that is supported, and allows it to be shared by both parties (with [[bip-0070.mediawiki|BIP70]], only the receiver could provide PKI information). This allows for automated creation of off-blockchain transaction logs that are human readable, now including information about the sender and not just the recipient.
 
 The motivation for this extension to [[bip-0070.mediawiki|BIP70]] is threefold:
 
@@ -38,12 +38,11 @@ The motivation for this extension to [[bip-0070.mediawiki|BIP70]] is threefold:
 
 # Enhance the Payment Protocol to allow for store and forward servers in order to allow, for example, mobile wallets to sign and serve Payment Requests.
 
-# Allow a sender of funds the option of sharing their identity with the receiver.  This information could then be used to:
+# Allow a sender of funds the option of sharing their identity with the receiver. This information could then be used to:
 
-#* Make Bitcoin logs more human readable
-#* Give the user the ability to decide who to release payment details to
-#* Allow an entity such as a political campaign to ensure donors match regulatory and legal requirements
-#* Allow for an open standards based way for regulated financial entities to meet regulatory requirements
+#* Make Bitcoin logs (wallet transaction history) more human readable
+#* Give the user the ability to decide whether or not they share their Bitcoin address and other payment details when requested
+#* Allow for an open standards based way for businesses to keep verifiable records of their financial transactions, to better meet the needs of accounting practices or other reporting and statutory requirements
 #* Automate the active exchange of payment addresses, so static addresses and BIP32 X-Pubs can be avoided to maintain privacy and convenience
 
 In short we wanted to make Bitcoin more human, while at the same time improving transaction privacy.
@@ -58,9 +57,9 @@ With this BIP, Bitcoin wallets could maintain an "address book" that only needs
 
 2. Individual Permissioned Address Release
 
-A Bitcoin wallet developer would like to allow users to view a potential sending party's identifying information before deciding whether or not to share payment information with them. Currently, [[bip-0070.mediawiki|BIP70]] specifies that the Merchant Server respond to a "pay now" style request with a PaymentRequest, releasing address and X.509 certificate identity information of the potential receiving party.
+A Bitcoin wallet developer would like to allow users to view a potential sending party's identifying information before deciding whether or not to share payment information with them. Currently, [[bip-0070.mediawiki|BIP70]] shares the receiver’s payment address and identity information with anyone who requests it.
 
-With this BIP, Bitcoin wallets could prompt a wallet user to release payment information while displaying identity information about the potential sending party via an included certificate. This gives the receiving party more control over who receives their payment and identity information, and could be helpful for businesses that need to follow KYC policies or wallets that want to focus on privacy.
+With this BIP, Bitcoin wallets could use the sender’s identifying information to make a determination of whether or not to share their own information. This gives the receiving party more control over who receives their payment and identity information. Additionally, this could be used to automatically provide new payment addresses to whitelisted senders, or to protect users’ privacy from unsolicited payment requests.
 
 3. Using Store & Forward Servers
 
@@ -110,10 +109,11 @@ message InvoiceRequest {
 This enum is used in the newly defined [[#ProtocolMessage|ProtocolMessage]] and [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] messages to define the serialized message type. The '''ProtocolMessageType''' enum is defined in an extensible way to allow for new message type additions to the Payment Protocol.
 <pre>
 enum ProtocolMessageType {
-    INVOICE_REQUEST = 0;
-    PAYMENT_REQUEST = 1;
-    PAYMENT = 2;
-    PAYMENT_ACK =  3;
+    UNKNOWN_TYPE = 0;
+    INVOICE_REQUEST = 1;
+    PAYMENT_REQUEST = 2;
+    PAYMENT = 3;
+    PAYMENT_ACK = 4;
 }
 </pre>
 
diff --git a/bip-0075/paymentrequest.proto b/bip-0075/paymentrequest.proto
index 3c1ef406..caab02a9 100644
--- a/bip-0075/paymentrequest.proto
+++ b/bip-0075/paymentrequest.proto
@@ -57,10 +57,11 @@ message InvoiceRequest {
 }
 
 enum ProtocolMessageType {
-    INVOICE_REQUEST = 0;
-    PAYMENT_REQUEST = 1;
-    PAYMENT = 2;
-    PAYMENT_ACK =  3;
+    UNKNOWN_TYPE = 0;
+    INVOICE_REQUEST = 1;
+    PAYMENT_REQUEST = 2;
+    PAYMENT = 3;
+    PAYMENT_ACK =  4;
 }
 
 message ProtocolMessage {

From 6559767e03dca8394fd28f1fb7b823d294e17d3b Mon Sep 17 00:00:00 2001
From: Matt David <matt@netki.com>
Date: Thu, 28 Jul 2016 15:13:32 -0700
Subject: [PATCH 10/13] - Replace UNKNOWN_TYPE with UNKNOWN_MESSAGE_TYPE

---
 bip-0075.mediawiki            | 2 +-
 bip-0075/paymentrequest.proto | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/bip-0075.mediawiki b/bip-0075.mediawiki
index 45ae282e..77616ba9 100644
--- a/bip-0075.mediawiki
+++ b/bip-0075.mediawiki
@@ -109,7 +109,7 @@ message InvoiceRequest {
 This enum is used in the newly defined [[#ProtocolMessage|ProtocolMessage]] and [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] messages to define the serialized message type. The '''ProtocolMessageType''' enum is defined in an extensible way to allow for new message type additions to the Payment Protocol.
 <pre>
 enum ProtocolMessageType {
-    UNKNOWN_TYPE = 0;
+    UNKNOWN_MESSAGE_TYPE = 0;
     INVOICE_REQUEST = 1;
     PAYMENT_REQUEST = 2;
     PAYMENT = 3;
diff --git a/bip-0075/paymentrequest.proto b/bip-0075/paymentrequest.proto
index caab02a9..9f170fe1 100644
--- a/bip-0075/paymentrequest.proto
+++ b/bip-0075/paymentrequest.proto
@@ -57,7 +57,7 @@ message InvoiceRequest {
 }
 
 enum ProtocolMessageType {
-    UNKNOWN_TYPE = 0;
+    UNKNOWN_MESSAGE_TYPE = 0;
     INVOICE_REQUEST = 1;
     PAYMENT_REQUEST = 2;
     PAYMENT = 3;

From c7fdd9d4289052a3fee8a82e9b8696ce3d11e8e4 Mon Sep 17 00:00:00 2001
From: jmacwhyte <keatonatron@gmail.com>
Date: Mon, 8 Aug 2016 22:04:33 -0700
Subject: [PATCH 11/13] Added additional pki_type values

---
 bip-0075.mediawiki | 20 ++++++++++++++++++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/bip-0075.mediawiki b/bip-0075.mediawiki
index 77616ba9..89ed5bf4 100644
--- a/bip-0075.mediawiki
+++ b/bip-0075.mediawiki
@@ -67,6 +67,21 @@ A Bitcoin wallet developer would like to use a public Store & Forward service fo
 
 With this BIP, returned payment information is encrypted with an ECDH-computed shared key before sending to a Store & Forward service. In this case, a successful attack against a Store & Forward service would not be able to read or modify wallet address or payment information, only delete encrypted messages.
 
+==Modifying BIP70 pki_type==
+This BIP adds additional possible values for the pki_type variable in the PaymentRequest message. The complete list is now as follows:
+
+{| class="wikitable"
+! pki_type !! Description
+|-
+| x509+sha256           || A x.509 certificate, as described in BIP70
+|-
+| pgp+sha256            || An [[https://en.wikipedia.org/wiki/Pretty_Good_Privacy#OpenPGP|OpenPGP]] certificate
+|-
+| ecdsa+sha256          || A [[https://en.bitcoin.it/wiki/Secp256k1|secp256k1]] [[https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm|ECDSA]] public key
+|}
+
+'''NOTE''': Although SHA1 was supported in BIP70, it has been deprecated and BIP75 only supports SHA256. The hashing algorithm is still specified in the values listed above for forward and backwards compatibility.
+
 ==New Messages==
 Updated [/bip-0075/paymentrequest.proto paymentrequest.proto] contains the existing PaymentRequest Protocol Buffer messages as well as the messages newly defined in this BIP.
 
@@ -94,7 +109,7 @@ message InvoiceRequest {
 |-
 | amount                || amount is integer-number-of-satoshis (default: 0)
 |-
-| pki_type              || none / x509+sha256 (default: "none")
+| pki_type              || none / x509+sha256 / pgp+sha256 / ecdsa+sha256 (default: "none")
 |-
 | pki_data              || Depends on pki_type
 |-
@@ -343,8 +358,9 @@ If a Store & Forward server wishes to protect themselves from spam or abuse, the
 Clients SHOULD keep in mind Receivers can broadcast a transaction without returning an ACK. If a Payment message needs to be updated, it SHOULD include at least one input referenced in the original transaction to prevent the Receiver from broadcasting both transactions and getting paid twice.
 
 ==Public Key & Signature Encoding==
-* All EC public keys ('''sender_public_key''', '''receiver_public_key''') included in any message defined in this BIP MUST be DER [ITU.X690.1994] encoded.
+* All EC public keys ('''sender_public_key''', '''receiver_public_key''') or x.509 certificates included in any message defined in this BIP MUST be DER [ITU.X690.1994] encoded.
 * All ECC signatures included in any message defined in this BIP MUST use the SHA-256 hashing algorithm and MUST be DER [ITU.X690.1994] encoded.
+* All OpenPGP certificates must follow [[https://tools.ietf.org/html/rfc4880|RFC4880]], sections 5.5 and 12.1.
 
 ==Implementation==
 A reference implementation for a Store & Forward server supporting this proposal can be found here:

From ac8a5f4df6d2f41b09379cffbb8897ccae16096f Mon Sep 17 00:00:00 2001
From: jmacwhyte <keatonatron@gmail.com>
Date: Mon, 29 Aug 2016 17:29:02 -0700
Subject: [PATCH 12/13] Added versioning, canceling

---
 bip-0075.mediawiki            | 66 ++++++++++++++++++++++-------------
 bip-0075/paymentrequest.proto | 42 +++++++++++-----------
 2 files changed, 64 insertions(+), 44 deletions(-)

diff --git a/bip-0075.mediawiki b/bip-0075.mediawiki
index 89ed5bf4..11fa43bb 100644
--- a/bip-0075.mediawiki
+++ b/bip-0075.mediawiki
@@ -136,46 +136,59 @@ enum ProtocolMessageType {
 The '''ProtocolMessage''' message is an encapsulating wrapper for any Payment Protocol message. It allows two-way, non-encrypted communication of Payment Protocol messages. The message also includes a status code and a status message that is used for error communication such that the protocol does not rely on transport-layer error handling.
 <pre>
 message ProtocolMessage {
-    required ProtocolMessageType message_type = 1;
-    required bytes serialized_message = 2;
-    optional uint64 status_code = 3;
-    optional string status_message = 4;
-    optional bytes identifier = 5;
+    required uint64 version = 1
+    required uint64 status_code = 2;
+    required ProtocolMessageType message_type = 3;
+    required bytes serialized_message = 4;
+    optional string status_message = 5;
+    optional bytes identifier = 6;
 }
 </pre>
 
 {| class="wikitable"
 ! Field Name !! Description
 |-
+|version                    || Protocol version number (Currently 1)
+|-
+|status_code                || Payment Protocol Status Code
+|-
 |message_type               || Message Type of serialized_message
 |-
 |serialized_message         || Serialized Payment Protocol Message
 |-
-|status_code                || Payment Protocol Status Code
-|-
 |status_message             || Human-readable Payment Protocol status message
 |-
 |identifier                 || Unique key to identify this entire exchange on the server. SHA256 of initial serialized InvoiceRequest SHOULD be used by default
 |}
 
+===Versioning===
+This BIP introduces version 1 of this protocol. All messages sent using these base requirements MUST use a value of 1 for the version number. Any future BIPs that modify this protocol (encryption schemes, etc) MUST each increment the version number by 1.
+
+When initiating communication, the version field of the first message SHOULD be set to the highest verison number the sender understands. All clients MUST be able to understand all version numbers less than the highest number they support. If a client receives a message with a version number higher than they understand, they MUST send the message back to the sender with a status code of 101 ("version too high") and the version field set to the highest version number the recipient understands. The sender must then resend the original message using the same version number returned by the recipient or abort.
+
 ===EncryptedProtocolMessage===
 The '''EncryptedProtocolMessage''' message is an encapsualting wrapper for any Payment Protocol message. It allows two-way, authenticated and encrypted communication of Payment Protocol messages in order to keep their contents secret. The message also includes a status code and status message that is used for error communication such that the protocol does not rely on transport-layer error handling.
 <pre>
 message EncryptedProtocolMessage {
-    required ProtocolMessageType message_type = 1;
-    required bytes encrypted_message = 2;
-    required bytes receiver_public_key = 3;
-    required bytes sender_public_key = 4;
-    required uint64 nonce = 5;
-    optional bytes signature = 6;
-    optional bytes identifier = 7;
-    optional uint64 status_code = 8;
+    required uint64 version = 1 [default = 1];
+    required uint64 status_code = 2 [default = 1];
+    required ProtocolMessageType message_type = 3;
+    required bytes encrypted_message = 4;
+    required bytes receiver_public_key = 5;
+    required bytes sender_public_key = 6;
+    required uint64 nonce = 7;
+    optional bytes identifier = 8;
     optional string status_message = 9;
+    optional bytes signature = 10;
 }
 </pre>
 {| class="wikitable"
 ! Field Name   !!  Description
 |-
+| version               || Protocol version number
+|-
+| status_code           || Payment Protocol Status Code
+|-
 | message_type          || Message Type of Decrypted encrypted_message
 |-
 | encrypted_message     || AES-256-GCM Encrypted (as defined in BIP75) Payment Protocol Message
@@ -186,13 +199,11 @@ message EncryptedProtocolMessage {
 |-
 | nonce                 || Microseconds since epoch
 |-
-| signature             || DER-encoded Signature over the full EncryptedProtocolMessage with EC Key Belonging to Sender / Receiver, respectively
-|-
 | identifier            || Unique key to identify this entire exchange on the server. SHA256 of initial serialized InvoiceRequest SHOULD be used by default
 |-
-| status_code           || Payment Protocol Status Code
-|-
 | status_message        || Human-readable Payment Protocol status message
+|-
+| signature             || DER-encoded Signature over the full EncryptedProtocolMessage with EC Key Belonging to Sender / Receiver, respectively
 |}
 
 ==Payment Protocol Process with InvoiceRequests==
@@ -236,9 +247,9 @@ When communicated via '''HTTP''', the listed messages MUST be transmitted via TL
 
 ===Payment Protocol Status Communication===
 
-In the case of an error that causes the Payment Protocol process to be stopped or requires that message be retried, a [[#ProtocolMessage|ProtocolMessage]] or [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] MUST be returned by the party generating the error status_code. The content of the message MUST contain the same '''serialized_message''' or '''encrypted_message''' and identifier (if present) and MUST have the status_code set appropriately. 
+Every [[#ProtocolMessage|ProtocolMessage]] or [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] MUST include a status code which conveys information about the last message received, if any (for the first message sent, use a status of 1 "OK" even though there was no previous message). In the case of an error that causes the Payment Protocol process to be stopped or requires that message be retried, a ProtocolMessage or EncryptedProtocolMessage SHOULD be returned by the party generating the error. The content of the message MUST contain the same '''serialized_message''' or '''encrypted_message''' and identifier (if present) and MUST have the status_code set appropriately. 
 <br/><br/>
-The status_message value SHOULD be set with a human readable explanation of the status code. For example, if in an [[#EncryptedProtocolMessage|EncryptedProtocolMessage]], the AES-256-GCM decryption fails to authenticate, an Authentication Failed (102) '''status_code''' MUST be returned to prevent oracle attacks.
+The status_message value SHOULD be set with a human readable explanation of the status code.
 
 ====Payment Protocol Status Codes====
 {| class="wikitable"
@@ -246,11 +257,15 @@ The status_message value SHOULD be set with a human readable explanation of the
 |- 
 | 1     || OK
 |-
+| 2     || Cancel
+|-
 | 100   || General / Unknown Error
 |-
+| 101   || Version Too High
+|-
 | 102   || Authentication Failed
 |-
-| 102   || Encrypted Message Required
+| 103   || Encrypted Message Required
 |-
 | 200   || Amount Too High
 |-
@@ -272,8 +287,10 @@ The status_message value SHOULD be set with a human readable explanation of the
 |-
 |}
 
-===Transport Layer Communication Errors===
++==Canceling A Message==+
+If a participant to a transaction would like to inform the other party that a previous message should be canceled, they can send the same message with a status code of 2 ("Cancel") and, where applicable, an updated nonce. How recipients make use of the "Cancel" message is up to developers. For example, wallet developers may want to offer users the ability to cancel payment requests they have sent to other users, and have that change reflected in the recipient's UI. Developers using the non-encrypted ProtocolMessage may want to ignore "Cancel" messages, as it may be difficult to authenticate that the message originated from the same user.
 
+===Transport Layer Communication Errors===
 Communication errors MUST be communicated to the party that initiated the communication via the communication layer's existing error messaging faciltiies. In the case of TLS-protected HTTP, this SHOULD be done through standard HTTP Status Code messaging ([https://tools.ietf.org/html/rfc7231 RFC 7231 Section 6]).
 
 ==Extended Payment Protocol Process Details==
@@ -306,6 +323,7 @@ For the following we assume the Sender already knows the Receiver's public key,
 * Encrypt the serialized Payment Protocol message using AES-256-CBC setup as described in [[#ECDH_Point_Generation_and_AES256_GCM_Mode_Setup|ECDH Point Generation and AES-256 (GCM Mode) Setup]]
 * Create [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] message
 * Set '''encrypted_message''' to be the encrypted value of the Payment Protocol message
+* '''version''' SHOULD be set to the highest version number the client understands (currently 1)
 * '''sender_public_key''' MUST be set to the public key of the Sender's EC keypair
 * '''receiver_public_key''' MUST be set to the public key of the Receiver's EC keypair
 * '''nonce''' MUST be set to the nonce used in the AES-256-CBC encryption operation
@@ -327,7 +345,7 @@ For the following we assume the Sender already knows the Receiver's public key,
 * Generate the '''secret point''' using [https://en.wikipedia.org/wiki/Elliptic_curve_Diffie–Hellman ECDH] using the local entity's private key and the remote entity's public key as inputs
 * Initialize [http://csrc.nist.gov/publications/nistpubs/800-90A/SP800-90A.pdf HMAC_DRBG]
 ** Use '''SHA512(secret point's X value in Big-Endian bytes)''' for Entropy
-** Use the given message's '''nonce''' field for Nonce
+** Use the given message's '''nonce''' field for Nonce, converted to byte string (Big Endian)
 
 * Initialize AES-256 in GCM Mode
 ** Initialize HMAC_DRBG with Security Strength of 256 bits
diff --git a/bip-0075/paymentrequest.proto b/bip-0075/paymentrequest.proto
index 9f170fe1..5a081920 100644
--- a/bip-0075/paymentrequest.proto
+++ b/bip-0075/paymentrequest.proto
@@ -48,12 +48,12 @@ message PaymentACK {
 // BIP-IR Extensions
 message InvoiceRequest {
         required bytes  sender_public_key = 1;              // Sender's DER-Encoded EC Public Key
-        optional uint64 amount = 3 [default = 0];           // amount is integer-number-of-satoshis
-        optional string pki_type = 4 [default = "none"];    // none / x509+sha256
-        optional bytes  pki_data = 5;                       // Depends on pki_type
-        optional string memo = 6;                           // Human-readable description of invoice request for the receiver
-        optional string notification_url = 7;               // URL to notify on EncryptedPaymentRequest ready
-        optional bytes  signature = 8;                      // PKI-dependent signature
+        optional uint64 amount = 2 [default = 0];           // amount is integer-number-of-satoshis
+        optional string pki_type = 3 [default = "none"];    // none / x509+sha256
+        optional bytes  pki_data = 4;                       // Depends on pki_type
+        optional string memo = 5;                           // Human-readable description of invoice request for the receiver
+        optional string notification_url = 6;               // URL to notify on EncryptedPaymentRequest ready
+        optional bytes  signature = 7;                      // PKI-dependent signature
 }
 
 enum ProtocolMessageType {
@@ -65,21 +65,23 @@ enum ProtocolMessageType {
 }
 
 message ProtocolMessage {
-    required ProtocolMessageType message_type = 1;  // Message Type of serialized_message
-    required bytes serialized_message = 2;          // Serialized Payment Protocol Message
-    optional uint64 status_code = 3;                // Payment Protocol Status Code
-    optional string status_message = 4;             // Human-readable Payment Protocol status message
-    optional bytes identifier = 5;                  // Unique key to identify this entire exchange on the server. SHA256 of initial serialized InvoiceRequest SHOULD be used by default
+    required uint64 version = 1 [default = 1];      // Protocol version number
+    required uint64 status_code = 2 [default = 1];  // Payment Protocol Status Code (Default: 1 "OK")
+    required ProtocolMessageType message_type = 3;  // Message Type of serialized_message
+    required bytes serialized_message = 4;          // Serialized Payment Protocol Message
+    optional string status_message = 5;             // Human-readable Payment Protocol status message
+    optional bytes identifier = 6;                  // Unique key to identify this entire exchange on the server. SHA256 of initial serialized InvoiceRequest SHOULD be used by default
 }
 
 message EncryptedProtocolMessage {
-    required ProtocolMessageType message_type = 1;  // Message Type of Decrypted encrypted_message
-    required bytes encrypted_message = 2;           // AES-256-GCM Encrypted (as defined in BIP75) Payment Protocol Message
-    required bytes receiver_public_key = 3;         // Receiver's DER-encoded EC Public Key
-    required bytes sender_public_key = 4;           // Sender's DER-encoded EC Public Key
-    required uint64 nonce = 5;                      // Microseconds since epoch
-    optional bytes signature = 6;                   // Signature over the full EncryptedProtocolMessage with EC Key Belonging to Sender / Receiver, respectively
-    optional bytes identifier = 7;                  // Unique key to identify this entire exchange on the server. SHA256 of initial serialized InvoiceRequest SHOULD be used by default
-    optional uint64 status_code = 8;                // Payment Protocol Status Code
-    optional string status_message = 9;            // Human-readable Payment Protocol status message
+    required uint64 version = 1 [default = 1];      // Protocol version number
+    required uint64 status_code = 2 [default = 1];  // Payment Protocol Status Code (Default: 1 "OK")
+    required ProtocolMessageType message_type = 3;  // Message Type of Decrypted encrypted_message
+    required bytes encrypted_message = 4;           // AES-256-GCM Encrypted (as defined in BIP75) Payment Protocol Message
+    required bytes receiver_public_key = 5;         // Receiver's DER-encoded EC Public Key
+    required bytes sender_public_key = 6;           // Sender's DER-encoded EC Public Key
+    required uint64 nonce = 7;                      // Microseconds since epoch
+    optional bytes identifier = 8;                  // Unique key to identify this entire exchange on the server. SHA256 of initial serialized InvoiceRequest SHOULD be used by default
+    optional string status_message = 9;             // Human-readable Payment Protocol status message
+    optional bytes signature = 10;                   // Signature over the full EncryptedProtocolMessage with EC Key Belonging to Sender / Receiver, respectively
 }
\ No newline at end of file

From 7ba8e5813a87a96ca3114a788e4913c2226404f3 Mon Sep 17 00:00:00 2001
From: Matt David <matt@netki.com>
Date: Tue, 30 Aug 2016 14:11:25 -0700
Subject: [PATCH 13/13] - Remove working copy of http address service bip

---
 bip-http-address-service.mediawiki | 125 -----------------------------
 1 file changed, 125 deletions(-)
 delete mode 100644 bip-http-address-service.mediawiki

diff --git a/bip-http-address-service.mediawiki b/bip-http-address-service.mediawiki
deleted file mode 100644
index bbb59217..00000000
--- a/bip-http-address-service.mediawiki
+++ /dev/null
@@ -1,125 +0,0 @@
-<pre>
-  BIP: XXX
-  Title: Endpoint Capability Discovering using HTTP Address Service
-  Author: Matt David <mgd@mgddev.com>
-          Frank Contreras <frank@frankintosh.net>
-  Status: Draft
-  Type: Standards Track
-  Created: 2016-06-10
-</pre>
-
-==Abstract==
-
-The proposed TLS-protected HTTP Address Service BIP aims to define a common flow for interacting with a TLS-protected HTTP Address Service such that Address Services can be provided to the client. Address Services may provide any of the following:
-
-# Wallet address
-# BitcoinURI
-# PaymentRequest
-# Store & Forward Services (supporting the Payment Protocol)
-
-The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 
-"OPTIONAL" in this document are to be interpreted as described in RFC 2119.
-
-==Motivation==
-
-As the use of bitcoin, as well as other blockchain-based currencies, digital assets, and payment networks continues to expand, the issue of address exchange becomes ever more important. With the introduction of safer, more secure, and user friendly address exchange processes such as [[bip-0075.mediawiki|BIP75]], there comes the issue of how to expose addresses. In order to negotiate for the most secure supported method of address exchange, we feel the best way is through a unique endpoint. This will serve HD wallet addresses and [[bip-0070.mediawiki|BIP70]] PaymentRequests as well as accept [[bip-0075.mediawiki|BIP75]] InvoiceRequests through a unique endpoint that can specifically expose supported methods via negotiation between the two parties. This specification proposes a standard HTTP flow for service discovery, wallet address retrieval (plaintext, BitcoinURI and PaymentRequest) as well as [[bip-0075.mediawiki|BIP75]] message passing.
-
-==Use Cases==
-
-===HD Wallet Address Exchange / BIP70 Endpoint===
-
-A bitcoin wallet developer would like to dynamically retrieve a unique address for a remote wallet. The developer would prefer a PaymentRequest, but would accept a BitcoinURI ([[bip-0021.mediawiki|BIP21]]). The Address Service spec allows the developer to discover which address options are available, if any. The developer can then specify which type of data they would prefer (based on availability) and submit a request for that data.
-
-===BIP75 InvoiceRequest Submission Endpoint===
-
-A bitcoin wallet developer would like to use [[bip-0075.mediawiki|BIP75]] to get a fully validated address. The Address Service specification allows the developer to discover if the receiving wallet (via the address endpoint) supports [[bip-0075.mediawiki|BIP75]]. Additionally, the Address Service specification provides the URI where a [[bip-0075.mediawiki|BIP75]] InvoiceRequest may be submitted if supported.
-
-==Details==
-
-===DANE / TLSA===
-
-Address Servers SHOULD be DANE / TLSA ([https://tools.ietf.org/html/rfc7671 RFC 7671]) enabled. 
-
-===Available Services===
-
-This flow will use a HTTP OPTIONS request to the address endpoint URL in order to determine service availability. The response will use the '''Allow''' (existing) and '''Accept''' (existing) HTTP headers to inform the client which services the address endpoint supports.
-
-====Allow Header Usage====
-
-The '''Allow''' header is used, as defined in [https://tools.ietf.org/html/rfc2616 RFC 2616] (14.7), to supply the client with supported HTTP methods for use with the address endpoint URL. The '''Allow''' header must return supported HTTP methods for the available return MIME types. See the table below for HTTP methods that relate to supported return MIME types.
-
-====Accept Header Usage====
-
-The '''Accept''' header is defined in [https://tools.ietf.org/html/rfc2616 RFC 2616] (14.1) and is used in the OPTIONS response. This header is generally used in the client request, but this specification uses it in the Address Service OPTIONS response.
-
-The '''Accept''' header MUST contain all acceptable MIME types for the endpoint. The following table defines MIME types for the appropriate return values:
-
-{| class="wikitable"
-! MIME Type !! HTTP Method !! HTTP Response Content
-|- 
-| text/plain                                                || GET  || Raw Wallet Address
-|-
-| application/bitcoin-uri                                   || GET  || Bitcoin URL ([[bip-0021.mediawiki|BIP21]] / [[bip-0072.mediawiki|BIP72]])
-|-
-| application/bitcoin-paymentrequest                        || GET  || [[bip-0070.mediawiki|BIP70]] PaymentRequest
-|-
-| application/bitcoin-paymentprotocol-message               || POST || [[bip-0075.mediawiki|BIP75]] ProtocolMessage 
-|-
-| application/bitcoin-encrypted-paymentprotocol-message     || POST || [[bip-0075.mediawiki|BIP75]] EncryptedProtocolMessage
-|-
-|}
-
-Based on the '''Allow''' and '''Accept''' headers in the OPTIONS response, the client MAY make another TLS-protected HTTP call to the URL using the HTTP method for the data type and the '''Accept''' value that the client requests.
-
-====Optional Public Key Sharing====
-
-In order to fully support [[bip-0075.mediawiki|BIP75]] Payment Protocol using EncryptedProtocolMessages, the Address Service MAY provide a '''receiver_public_key''' for the address endpoint by including the '''X-Identity''' HTTP header in the response. The contents of the '''X-Identity''' header MUST be a hex-encoded, DER-formatted EC Public Key.
-
-===Raw Wallet Addresses, BitcoinURIs and PaymentRequests===
-
-====Request====
-
-A HTTP GET request on a TLS-protected HTTP address endpoint MUST set the '''Accept''' header to the requested content type. This requested content type MUST have been listed in the '''Accept''' header of the previous OPTIONS response. 
-
-====Response====
-
-The Address Service MUST respond with the appropriate requested data type and a HTTP Status Code of '''200 (OK)'''. 
-
-If the data type is temporarily unavailable and should be retried later, the Address Service MUST respond with a HTTP Status Code of 503 (Service Unavailable). The Address Service MAY include a '''Retry-After''' HTTP Header if it can determine when an appropriate response will be available.
-
-If the data type is permanently unavailable, for example if the address endpoint has been disabled, the Address Service MUST respond with a HTTP Status Code of 410 (Gone).
-
-===Handling BIP75 Messages===
-
-====Request====
-
-A HTTP POST request on a TLS-protected HTTP address endpoint MUST set the '''Accept''' header to the requested response MIME Type. The available response MIME Types for this request are:
-
-* application/bitcoin-paymentprotocol-message
-* application/bitcoin-encrypted-paymentprotocol-message
-
-The HTTP POST request MUST set the '''Content-Transfer-Encoding''' header to "binary" and the '''Content-Type''' header to either of the aforementioned MIME Types. The content of the POST message MUST be the binary representation of a serialized ProtocolMessage or EncryptedProtocolMessage.
-
-====Immediate Response====
-
-The Address Service MUST respond with a HTTP Status Code of '''200 (OK)''' if the response type is a ProtocolMessage or EncryptedProtocolMessage. The Address Service MUST respond with a ProtocolMessage or EncryptedProtocolMessage based on the '''Accept''' header in the client request.
-
-====Delayed Response====
-
-The Address Service MUST respond with a HTTP Status Code of '''202 (Accepted)''' and the '''Location''' header set to a location to later retrieve the resulting ProtocolMessage or EncryptedProtocolMessage
-
-'''NOTE''': [[bip-0075.mediawiki|BIP75]] messages SHOULD be transmitted using EncryptedProtocolMessage message types in order to provide additional application-layer security.
-
-
-==Implementation==
-
-TBD
-
-==References==
-* [[bip-0021.mediawiki|BIP21 - URI Scheme]]
-* [[bip-0070.mediawiki|BIP70 - Payment Protocol]]
-* [[bip-0072.mediawiki|BIP72 - bitcoin: URI Extensions for Payment Protocol]]
-* [[bip-0075.mediawiki|BIP75 - Out of Band Address Exchange using Payment Protocol Encryption]]
-* [https://tools.ietf.org/html/rfc2616 RFC2616 - Hypertext Transfer Protocol -- HTTP/1.1]
-* [https://tools.ietf.org/html/rfc6698 RFC6698 - The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA]
-* [https://tools.ietf.org/html/rfc7671 RFC7671 - The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance]
\ No newline at end of file