bitcoin/bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-10-27 14:09:10 +00:00
Code Issues 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 | Standard
| Draft | 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]] | [[bip-0080.mediawiki|80]]
| Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets | Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets
| Justus Ranvier, Jimmy Song | Justus Ranvier, Jimmy Song
@ -332,12 +338,6 @@ Those proposing changes should consider that ultimately consent may rest with th
| Standard | Standard
| Draft | 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]] | [[bip-0099.mediawiki|99]]
| Motivation and deployment of consensus rule changes ([soft/hard]forks) | Motivation and deployment of consensus rule changes ([soft/hard]forks)
| Jorge Timón | 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 | Field Number || Extension Name || Field Name || Description
|- |-
| 1000 || [[https://example.com|(unassigned)]] || (unassigned) || (unassigned) | 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. 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. # 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: 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. # 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: # 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 #* Make Bitcoin logs more human readable
#* Give the user the ability to decide who to release payment details to #* 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 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 #* 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 #* 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; required uint64 nonce = 5;
optional bytes signature = 6; optional bytes signature = 6;
optional bytes identifier = 7; optional bytes identifier = 7;
} }
</pre> </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 # 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. '''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"> <img src="bip-0075/encrypted-invoice-request-process.png" alt="Flow diagram of Encrypted InvoiceRequest">
==Message Interaction Details== ==Message Interaction Details==
@ -334,7 +333,7 @@ Where used, '''nonce''' MUST be set to a non-repeating number AND MUST be chosen
===InvoiceRequest Validation=== ===InvoiceRequest Validation===
* Validate sender_public_key is a valid EC public key * 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). * 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 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 * 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=== ===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. * 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 '''secret point's''' X value for Entropy
** Use the given message's nonce field for Nonce ** Use the given message's nonce field for Nonce
* Initialize AES-256 in CBC Mode * 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. * 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== ==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] [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] [https://github.com/netkicorp/addressimo/blob/master/functest/functest_ir.py InvoiceRequest Client Reference Implementation]