highperfocused/bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-03-17 21:32:50 +01:00
Code Issues Packages Projects Releases Wiki Activity

- Add qualifier that nonce MUST be chosen by the encryptor.

Browse Source 
- Also, fix ** used for bold and replace with <b></b>
This commit is contained in:
Matt David 2016-02-22 13:47:49 -08:00
parent 8dffb2e58a
commit ca0f07cfa7
1 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
bip-invoicerequest-extension.mediawiki
View File

@ -321,7 +321,7 @@ SHOULD be done through standard HTTP Status Code messaging ([https://tools.ietf.
For the following we assume the Sender already knows the Receiver's public key, and the exchange is being facilitated by a Store & Forward server which requires valid signatures for authentication.
Where used, **nonce** MUST be set to a non-repeating number. The current epoch time in microseconds SHOULD be used, unless the creating device doesn't have access to a RTC (in the case of a smart card, for example). The service receiving the message containing the **nonce** MAY use whatever method to make sure that the **nonce** is never repeated.
Where used, <b>nonce</b> MUST be set to a non-repeating number AND MUST be chosen by the encryptor. The current epoch time in microseconds SHOULD be used, unless the creating device doesn't have access to a RTC (in the case of a smart card, for example). The service receiving the message containing the <b>nonce</b> MAY use whatever method to make sure that the <b>nonce</b> is never repeated.
===InvoiceRequest Message Creation===
* Create an InvoiceRequest message
@ -418,7 +418,7 @@ Initial public key retrieval for InvoiceRequest encryption can be done in a numb
* Set signature to the result of the signature operation above
**SIGNATURE NOTE:** EncryptedPaymentRequest, EncryptedPayment, and EncryptedPaymentACK messages are signed with the public keys of the party transmitting the message. This allows a Store & Forward server or other transmission system to prevent spam or other abuses. For those who are privacy concious and don't want the server to track the interactions between two public keys, the Sender can generate a new public key for each interaction to keep their identity anonymous.
<b>SIGNATURE NOTE:</b> EncryptedPaymentRequest, EncryptedPayment, and EncryptedPaymentACK messages are signed with the public keys of the party transmitting the message. This allows a Store & Forward server or other transmission system to prevent spam or other abuses. For those who are privacy concious and don't want the server to track the interactions between two public keys, the Sender can generate a new public key for each interaction to keep their identity anonymous.
==Payment / PaymentACK Messages with a Store & Foward Server==
When a Store & Forward server is in use during the Payment Protocol exchange, an EncryptedPayment message generated as the result of a EncryptedPaymentRequest with the requires_payment_message flag set to true MUST be accepted by a Store & Forward server. The accepted Payment message is NOT validated as the Store & Forward server does not have access to encrypted data.