summaryrefslogtreecommitdiff
path: root/bip-0075.mediawiki
diff options
context:
space:
mode:
authorMatt David <matt@netki.com>2016-04-26 18:53:05 -0700
committerMatt David <matt@netki.com>2016-04-26 18:53:05 -0700
commitb5517bab86c7039e654cc1c1f6584808a3cbba39 (patch)
treec4e3ba99abaf495ba4cd707bc7ca6df994e67ac0 /bip-0075.mediawiki
parent32d9f9d266f7bca15ea248b15a75092a46a61902 (diff)
downloadbips-b5517bab86c7039e654cc1c1f6584808a3cbba39.tar.xz
Add more linebreaks
Diffstat (limited to 'bip-0075.mediawiki')
-rw-r--r--bip-0075.mediawiki12
1 files changed, 6 insertions, 6 deletions
diff --git a/bip-0075.mediawiki b/bip-0075.mediawiki
index 32649c9..95e620f 100644
--- a/bip-0075.mediawiki
+++ b/bip-0075.mediawiki
@@ -182,11 +182,11 @@ message EncryptedProtocolMessage {
==Payment Protocol Process with InvoiceRequests==
The full process overview for using '''InvoiceRequests''' in the Payment Protocol is defined below.
-<br/>
+<br/><br/>
All Payment Protocol messages MUST be encapsulated in either a [[#ProtocolMessage|ProtocolMessage]] or [[#EncryptedProcotolMessage|EncryptedProtocolMessage]]. Once the process begins using [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] messages, all subsequent communications MUST use [[#EncryptedProtocolMessage|EncryptedProtocolMessages]].
-<br/>
+<br/><br/>
All Payment Protocol messages SHOULD be communicated using [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] encapsulating messages with the exception that an [[#InvoiceRequest|InvoiceRequest]] MAY be communicated using the [[#ProtocolMessage|ProtocolMessage]] if the receiver's public key is unknown.
-<br/>
+<br/><br/>
The process of communicating using encrypted Payment Protocol messages is enumerated in [[#Sending_Encrypted_Payment_Protocol_Messages_using_EncryptedProtocolMessages|Sending Encrypted Payment Protocol Messages using EncryptedProtocolMessages]] and [[#Validating_and_Decrypting_Payment_Protocol_Messages_using_EncryptedProtocolMessages|Validating and Decrypting Payment Protocol Messages using EncryptedProtocolMessages]].
# Sender creates InvoiceRequest
@@ -219,7 +219,7 @@ 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.
-<br/>
+<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.
====Payment Protocol Status Codes====
@@ -322,9 +322,9 @@ Initial public key retrieval for [[#InvoiceRequest|InvoiceRequest]] encryption v
==Payment / PaymentACK Messages with a HTTP Store & Forward Server==
A Store & Forward server SHOULD store PaymentRequest messages until either a timeout expires the message or a Payment message for the PaymentRequest message has been received. The timeout SHOULD be greater than 24 hours.
-<br/>
+<br/><br/>
When a Store & Forward server is used for a Payment Protocol exchange, a Payment message generated as the result of a PaymentRequest MUST be accepted by a Store & Forward server if the associated PaymentRequest message exists on the Store & Forward server, otherwise an HTTP 404 Not Found message should be returned. The accepted Payment message is NOT validated as the Store & Forward server does not have access to encrypted data.
-<br/>
+<br/><br/>
Store & Forward servers MAY accept and/or overwrite Payment messages until an PaymentACK message with matching identifier and valid Receiver signature is received, after which the server MAY reject all further Payment messages matching that identifier. This feature SHOULD be used for updating Payment metadata or replacing invalid transactions with valid ones. 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==