mirrors/bitcoin-bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-01-18 21:35:13 +01:00
Code Issues Projects Releases Wiki Activity

Include grammar fixes from Dawn

Browse Source
This commit is contained in:
Matt David 2016-02-17 16:11:59 -08:00
parent 7a92454e54
commit 0c3d6d15ae
1 changed files with 12 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
bip-invoicerequest-extension.mediawiki
View File

@ -14,20 +14,27 @@
This BIP is an extension to BIP 70 that provides two enhancements to the existing Payment Protocol. This BIP is an extension to BIP 70 that provides two enhancements to the existing Payment Protocol.
# It allows the requestor of a Payment Request to voluntarily sign the original request and provide a certificate to allow the payee to know the identity of who they are transacting with. # It allows the requestor (Sender) of a Payment Request to voluntarily sign the original request and provide a certificate to allow the payee to know the identity of who they are transacting with.
# It encrypts the Payment Request that is returned, before handing it off to the SSL/TLS layer to prevent man in the middle viewing of the Payment Request details. # It encrypts the Payment Request that is returned, before handing it off to the SSL/TLS layer to prevent man in the middle viewing of the Payment Request details.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 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. "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
==Definitions==
{| class="wikitable"
| Sender || Entity wishing to transfer value that they control
|-
| Receiver || Entity receiving a value transfer
|}
==Motivation== ==Motivation==
The motivation for defining this extension to the 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 requestor 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 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 requestor 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 this extension to BIP70 is threefold: The motivation for this extension to BIP70 is threefold:
# Ensure that the payment details can only be seen by the participants in the transaction, and not any third party. # Ensure that the payment details can only be seen by the participants in the transaction, and not by any third party.
# Enhance the Paument Protocol to allow for store and forward servers in order to allow, for example, mobile wallets to sign and serve Payment Requests. # Enhance the Paument Protocol to allow for store and forward servers in order to allow, for example, mobile wallets to sign and serve Payment Requests.
@ -41,13 +48,6 @@ The motivation for this extension to BIP70 is threefold:
In short we wanted to make bitcoin more human, while at the same time improving transaction privacy. In short we wanted to make bitcoin more human, while at the same time improving transaction privacy.
==Definitions==
{| class="wikitable"
| Sender || Entity wishing to transfer value that they control
|-
| Receiver || Entity receiving a value transfer
|}
==Example Use Cases== ==Example Use Cases==
1. Address Book 1. Address Book
@ -56,7 +56,7 @@ Let's say a Bitcoin wallet developer would like to offer the ability to store an
send multiple payments to known entities without having to request an address every time. Static addresses compromise send multiple payments to known entities without having to request an address every time. Static addresses compromise
privacy, and address reuse is considered a security risk. BIP32 X-Pubs allow the generation of unique addresses, but privacy, and address reuse is considered a security risk. BIP32 X-Pubs allow the generation of unique addresses, but
watching an X-Pub chain for each person you wish to receive funds from is too resource-intensive for mobile applications, watching an X-Pub chain for each person you wish to receive funds from is too resource-intensive for mobile applications,
and there is always the risk of unknowingly sending funds to an X-Pub address after the owner has lost access to the and there is always a risk of unknowingly sending funds to an X-Pub address after the owner has lost access to the
corresponding private key. corresponding private key.
With this BIP, Bitcoin wallets could maintain an "address book" that only needs to store each payee's public key. Adding With this BIP, Bitcoin wallets could maintain an "address book" that only needs to store each payee's public key. Adding
@ -68,7 +68,7 @@ or destroyed, no communication will be possible, and the sending of funds to a "
2. Individual Permissioned Address Release 2. Individual Permissioned Address Release
Let's say a Bitcoin wallet developer would like to offer the ability for a user to individually release address information Let's say a Bitcoin wallet developer would like to offer the ability for a user to individually release address information
to a new potential sending party only if they can confirm the identity of the potential sending party. BIP70 specifies that to a new potential sending party only if they can confirm the identity of the potential sending party. Currently, BIP70 specifies that
the Merchant Server respond to a "pay now" style request with a PaymentRequest, releasing address and X.509 certificate identity 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. information of the potential receiving party.
@ -311,3 +311,4 @@ of an InvoiceRequest, a Store & Forward server, and a EncryptedPaymentRequest.
* [https://en.wikipedia.org/wiki/Elliptic_curve_Diffie–Hellman ECDH] * [https://en.wikipedia.org/wiki/Elliptic_curve_Diffie–Hellman ECDH]
* [http://csrc.nist.gov/publications/nistpubs/800-90A/SP800-90A.pdf HMAC_DRBG] * [http://csrc.nist.gov/publications/nistpubs/800-90A/SP800-90A.pdf HMAC_DRBG]
* [https://tools.ietf.org/html/rfc6979 RFC6979] * [https://tools.ietf.org/html/rfc6979 RFC6979]
* [https://en.bitcoin.it/wiki/Address_reuse Address Reuse]