Skip to content

Commit 5ec3d52

Browse files
author
Matt David
committed
Updating abstract and motivation with changes made by the Netki team
1 parent 58754bd commit 5ec3d52

1 file changed

Lines changed: 19 additions & 9 deletions

File tree

bip-invoicerequest-extension.mediawiki

Lines changed: 19 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -12,20 +12,30 @@
1212

1313
==Abstract==
1414

15-
This BIP is an extension to BIP70 that extends the payment protocol to prevent PaymentRequest interception / modification
16-
during transmission using ephemeral key encryption. This also allows permissioned release of a PaymentRequest to a requestor
17-
and allows a requestor to supply a certificate and signature to the PaymentRequest creator.
15+
This BIP is an extension to BIP 70 that provides two enhancements to the existing Payment Protocol.
1816

19-
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
17+
# It allows the requestor of a Payment Request to voluntarily sign the original request and provide a certificate to allow the payee to know who they are transacting with.
18+
19+
# 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.
20+
21+
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
2022
"OPTIONAL" in this document are to be interpreted as described in RFC 2119.
2123

2224
==Motivation==
2325

24-
The motivation for defining this extension to the BIP70 Payment Protocol is to allow 2 parties to exchange payment
25-
information in a permissioned and encrypted way such that wallet address communication can become a more automated process.
26-
Additionally, this extension allows for the requestor of a PaymentRequest to supply a certificate and signature in order
27-
to facilitate identification for address release. This also allows for automated creation of off blockchain transaction
28-
logs that are human readable, containing who you transacted with, in addition to the information that it contains today.
26+
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.
27+
28+
The motivation for this extension to BIP70 is twofold:
29+
30+
# Ensure that the payment details can only be seen by the participants in the transaction, and not any third party. By encrypting at the application layer we protect the payment request from being intercepted by a man in the middle, and allow mobile and desktop wallets to use a server to act as a “store and forward server” or “meet point” for serving Payment Requests without having to worry the server operator can spy on their transactions.
31+
32+
# Allow a sender of funds the option of sharing their identity with the receiver. This information could then be used to:
33+
** Make bitcoin logs more human readable
34+
** Give the user the ability to decide who to release payment details to
35+
** Allow an entity such as a political campaign to ensure donors match regulatory and legal requirements
36+
** Allow for an open standards based way to meet regulatory requirements
37+
38+
In short we wanted to make bitcoin more human, while at the same time improving transaction privacy.
2939

3040
==Definitions==
3141
{| class="wikitable"

0 commit comments

Comments
 (0)