From 22646636dd79518691a5ba5ed51bc35a84d11d49 Mon Sep 17 00:00:00 2001 From: Ross Nicoll Date: Sat, 26 Apr 2014 16:25:22 +0100 Subject: [PATCH 1/5] Replaced example domain name with example.com. --- bip-0070.mediawiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip-0070.mediawiki b/bip-0070.mediawiki index 3e861db2..1ee56bd2 100644 --- a/bip-0070.mediawiki +++ b/bip-0070.mediawiki @@ -25,7 +25,7 @@ The current, minimal Bitcoin payment protocol operates as follows: This BIP extends the above protocol to support several new features: -# Human-readable, secure payment destinations-- customers will be asked to authorize payment to "website.com" instead of an inscrutable, 34-character bitcoin address. +# Human-readable, secure payment destinations-- customers will be asked to authorize payment to "example.com" instead of an inscrutable, 34-character bitcoin address. # Secure proof of payment, which the customer can use in case of a dispute with the merchant. # Resistance from man-in-the-middle attacks that replace a merchant's bitcoin address with an attacker's address before a transaction is authorized with a hardware wallet. # Payment received messages, so the customer knows immediately that the merchant has received, and has processed (or is processing) their payment. From 694314d296cff6871b9e58c2b2b8f07305cb8a4a Mon Sep 17 00:00:00 2001 From: Ross Nicoll Date: Sat, 26 Apr 2014 16:44:13 +0100 Subject: [PATCH 2/5] Added file size limits for Payment and PaymentACK messages. --- bip-0070.mediawiki | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/bip-0070.mediawiki b/bip-0070.mediawiki index 1ee56bd2..84a85593 100644 --- a/bip-0070.mediawiki +++ b/bip-0070.mediawiki @@ -172,6 +172,9 @@ determine whether or not the transactions satisfy conditions of payment. If and only if they do, if should broadcast the transaction(s) on the Bitcoin p2p network. +Payment messages larger than 50,000 bytes should be rejected by +the merchant's server, to mitigate denial-of-service attacks. + ===PaymentACK=== PaymentACK is the final message in the payment protocol; it is sent @@ -189,6 +192,11 @@ Payment message: | memo || UTF-8 encoded note that should be displayed to the customer giving the status of the transaction (e.g. "Payment of 1 BTC for eleven tribbles accepted for processing.") |} +PaymentACK messages larger than 60,000 bytes should be rejected by +the wallet application, to mitigate denial-of-service attacks. This +is larger than the limits on Payment and PaymentRequest messages +as PaymentACK contains a full Payment message within it. + ==Localization== Merchants that support multiple languages should generate From d8bd74baf841f0d82a1b2b8af8ece37df50b06d4 Mon Sep 17 00:00:00 2001 From: Ross Nicoll Date: Sat, 26 Apr 2014 16:59:23 +0100 Subject: [PATCH 3/5] Added note about handling multiple copies of a Payment message, to ensure resend is safe in case of a transport layer failure. --- bip-0070.mediawiki | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/bip-0070.mediawiki b/bip-0070.mediawiki index 84a85593..b541cbcd 100644 --- a/bip-0070.mediawiki +++ b/bip-0070.mediawiki @@ -156,6 +156,11 @@ If the customer authorizes payment, then the Bitcoin client: # If PaymentDetails.payment_url is specified, POST a Payment message to that URL. The Payment message is serialized and sent as the body of the POST request. Errors communicating with the payment_url server should be communicated to the user. +The merchant's server should handle receiving multiple copies of the same Payment +message in response to a single PaymentRequest. This is required to ensure that in +case of a transport level failure during transmission, recovery is possible by +re-sending the Payment message. The endpoint URL must remain valid for at least +the same period of time as the original PaymentRequest. PaymentDetails.payment_url should be secure against man-in-the-middle attacks that might alter Payment.refund_to (if using HTTP, it must be From 89050ce1462f7a18898c884503966a9cf6f1f22b Mon Sep 17 00:00:00 2001 From: Ross Nicoll Date: Sun, 27 Apr 2014 00:43:47 +0100 Subject: [PATCH 4/5] Expanded and clarified wording on recovering from error states when sending payment to the merchant's server. --- bip-0070.mediawiki | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/bip-0070.mediawiki b/bip-0070.mediawiki index b541cbcd..747295ce 100644 --- a/bip-0070.mediawiki +++ b/bip-0070.mediawiki @@ -99,6 +99,12 @@ about the merchant and a digital signature. | merchant_data || Arbitrary data that may be used by the merchant to identify the PaymentRequest. May be omitted if the merchant does not need to associate Payments with PaymentRequest or if they associate each PaymentRequest with a separate payment address. |} +The payment_url specified in the PaymentDetails must remain valid at least until the PaymentDetails +expires (or indefinitely if the PaymentDetails does not expire). Note that this is irrespective of +any state change in the underlying payment request; for example cancellation of an order should not +invalidate the payment_url, as it is important that the merchant's server can record mis-payments +in order to refund the payment. + A PaymentRequest is PaymentDetails optionally tied to a merchant's identity: 
     message PaymentRequest {
@@ -156,11 +162,13 @@ If the customer authorizes payment, then the Bitcoin client:
 # If PaymentDetails.payment_url is specified, POST a Payment message to that URL. The Payment message is serialized and sent as the body of the POST request.
 
 Errors communicating with the payment_url server should be communicated to the user.
-The merchant's server should handle receiving multiple copies of the same Payment
-message in response to a single PaymentRequest. This is required to ensure that in
-case of a transport level failure during transmission, recovery is possible by
-re-sending the Payment message. The endpoint URL must remain valid for at least
-the same period of time as the original PaymentRequest.
+In the scenario where the merchant's server receives multiple identical Payment
+messages for an individual PaymentRequest, it must acknowledge each. The second
+and further PaymentACK messages sent from the merchant's server may vary by memo
+field to indicate current state of the Payment (for example number of confirmations
+seen on the network). This is required in order to ensure that in case of a transport
+level failure during transmission, recovery is possible by the Bitcoin client
+re-sending the Payment message.
 
 PaymentDetails.payment_url should be secure against man-in-the-middle
 attacks that might alter Payment.refund_to (if using HTTP, it must be

From 9d8e00207125d844e49e25b0fefeefa263287f2c Mon Sep 17 00:00:00 2001
From: Ross Nicoll 
Date: Sun, 27 Apr 2014 21:08:44 +0100
Subject: [PATCH 5/5] Loosened URL validity period on payment requests.

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

diff --git a/bip-0070.mediawiki b/bip-0070.mediawiki
index 747295ce..a65e5a5e 100644
--- a/bip-0070.mediawiki
+++ b/bip-0070.mediawiki
@@ -99,8 +99,8 @@ about the merchant and a digital signature.
 | merchant_data || Arbitrary data that may be used by the merchant to identify the PaymentRequest. May be omitted if the merchant does not need to associate Payments with PaymentRequest or if they associate each PaymentRequest with a separate payment address.
 |}
 
-The payment_url specified in the PaymentDetails must remain valid at least until the PaymentDetails
-expires (or indefinitely if the PaymentDetails does not expire). Note that this is irrespective of
+The payment_url specified in the PaymentDetails should remain valid at least until the PaymentDetails
+expires (or as long as possible if the PaymentDetails does not expire). Note that this is irrespective of
 any state change in the underlying payment request; for example cancellation of an order should not
 invalidate the payment_url, as it is important that the merchant's server can record mis-payments
 in order to refund the payment.