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

Put BIP 75 in the right place in README, and clean up formatting a bit

Browse Source
This commit is contained in:
Luke Dashjr 2016-03-17 05:21:40 +00:00
parent 9d86a41747
commit 19845126ec
3 changed files with 17 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
README.mediawiki
View File

@ -314,6 +314,12 @@ Those proposing changes should consider that ultimately consent may rest with th
| Standard
| Draft
|-
| [[bip-0075.mediawiki|75]]
| Out of Band Address Exchange using Payment Protocol Encryption
| Justin Newton, Matt David, Aaron Voisine, James MacWhyte
| Standard
| Draft
|-
| [[bip-0080.mediawiki|80]]
| Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets
| Justus Ranvier, Jimmy Song
@ -332,12 +338,6 @@ Those proposing changes should consider that ultimately consent may rest with th
| Standard
| Draft
|-
| [[bip-0075.mediawiki|75]]
| Out of Band Address Exchange using Payment Protocol Encryption
| Justin Newton, Matt David, Aaron Voisine and James MacWhyte
| Standard
| Draft
|-
| [[bip-0099.mediawiki|99]]
| Motivation and deployment of consensus rule changes ([soft/hard]forks)
| Jorge Timón

2
bip-0070/extensions.mediawiki
View File

@ -6,4 +6,4 @@ Add your extension below using tags starting at 1000 and submit a pull-req.
| Field Number || Extension Name || Field Name || Description
|-
| 1000 || [[https://example.com|(unassigned)]] || (unassigned) || (unassigned)
|}
|}

21
bip-0075.mediawiki
View File

@ -14,7 +14,7 @@
This BIP is an extension to BIP 70 that provides two enhancements to the existing Payment Protocol.
# It allows the requester (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 allows the requester (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.
@ -34,15 +34,15 @@ The motivation for defining this extension to the BIP70 Payment Protocol is to a
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 by 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 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:
#* 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
#* 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
#* Automate the active exchange of payment addresses, so static addresses and BIP32 X-Pubs can be avoided to maintain privacy and convenience
@ -118,7 +118,6 @@ message EncryptedInvoiceRequest {
required uint64 nonce = 5;
optional bytes signature = 6;
optional bytes identifier = 7;
}
</pre>
@ -277,7 +276,7 @@ The process overview for using InvoiceRequests and receiving encrypted PaymentRe
# The PaymentRequest is processed according to BIP70, including optional EncryptedPayment and EncryptedPaymentACK messages
'''NOTE:''' See section [[#Initial_Public_Key_Retrieval_for_InvoiceRequest_Encryption|Initial Public Key Retrieval for InvoiceRequest Encryption]] below for possible options to retrieve Receiver InvoiceRequest public keys.
<img src="bip-0075/encrypted-invoice-request-process.png" alt="Flow diagram of Encrypted InvoiceRequest">
==Message Interaction Details==
@ -334,7 +333,7 @@ Where used, '''nonce''' MUST be set to a non-repeating number AND MUST be chosen
===InvoiceRequest Validation===
* Validate sender_public_key is a valid EC public key
* The nonce MUST not be repeated. The service receiving the InvoiceRequest MAY use whatever method to make sure that the nonce is never repeated.
* The nonce MUST not be repeated. The service receiving the InvoiceRequest MAY use whatever method to make sure that the nonce is never repeated.
* Validate notification_url if set, contains characters deemed valid for a URL (avoiding XSS related characters, etc).
* If pki_type is None, InvoiceRequest is VALID
* If pki_type is x509+sha256 and signature is valid for the serialized InvoiceRequest where signature is set to "", InvoiceRequest is VALID
@ -360,7 +359,7 @@ Where used, '''nonce''' MUST be set to a non-repeating number AND MUST be chosen
===ECDH Point Generation and AES-256 (CBC Mode) Setup===
* 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]
* Initialize [http://csrc.nist.gov/publications/nistpubs/800-90A/SP800-90A.pdf HMAC_DRBG]
** Use '''secret point's''' X value for Entropy
** Use the given message's nonce field for Nonce
* Initialize AES-256 in CBC Mode
@ -414,11 +413,11 @@ Store & Forward servers MAY accept and/or overwrite EncryptedPayment messages un
* Each ECC signature included in any message defined in this BIP MUST use the SHA-256 hashing algorithm and MUST be DER [ITU.X690.1994] encoded.
==Implementation==
A reference implementation for a Store & Forward server supporting this proposal can be found here:
A reference implementation for a Store & Forward server supporting this proposal can be found here:
[https://github.com/netkicorp/addressimo Addressimo]
A reference client implementation can be found in the InvoiceRequest functional testing for Addressimo here:
A reference client implementation can be found in the InvoiceRequest functional testing for Addressimo here:
[https://github.com/netkicorp/addressimo/blob/master/functest/functest_ir.py InvoiceRequest Client Reference Implementation]