summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMatt David <matt.david@me.com>2016-02-02 10:24:08 -0800
committerMatt David <matt.david@me.com>2016-02-02 10:24:08 -0800
commit06c3c1b4887bbe567defa9ddbad12a8ce3436c5c (patch)
treed614dd75391fe7c27b1f00cc5416f816cf6e8248
parent88898c2f873946f9960a5146b0bcfa27bb60cf92 (diff)
parenta715f2cdb18c9881bfba97a188e870cc12c5ecd8 (diff)
downloadbips-06c3c1b4887bbe567defa9ddbad12a8ce3436c5c.tar.xz
Merge pull request #3 from jmacwhyte/proofread
Added example use case.
-rw-r--r--bip-invoicerequest-extension.mediawiki8
1 files changed, 7 insertions, 1 deletions
diff --git a/bip-invoicerequest-extension.mediawiki b/bip-invoicerequest-extension.mediawiki
index c905e29..80d9f1e 100644
--- a/bip-invoicerequest-extension.mediawiki
+++ b/bip-invoicerequest-extension.mediawiki
@@ -35,10 +35,16 @@ The motivation for this extension to BIP70 is twofold:
* 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 to meet regulatory requirements
-* Automate the creation and maintenance of an "address book" of payees, without relying on static addresses or BIP32 X-Pubs which can become outdated and/or compromise privacy
+* Automate the active exchange of payment addresses, so static addresses and BIP32 X-Pubs can be avoided to maintain privacy and convenience
In short we wanted to make bitcoin more human, while at the same time improving transaction privacy.
+==Example Use Case==
+
+Let's say a Bitcoin wallet developer would like to offer the ability to store an "address book" of payees, so users could 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 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 corresponding private key.
+
+With this BIP, Bitcoin wallets could maintain an "address book" that only needs to store each payee's public key. Adding an entry to one's address book could be done by scanning a QR code, sending a URI through a text message or e-mail, or searching a public repository. When the user wishes to make a payment, their wallet would do all the work in the background to communicate with the payee's wallet to receive a unique payment address. If the payee's wallet has been lost, replaced, or destroyed, no communication will be possible, and the sending of funds to a "dead" address is prevented.
+
==Definitions==
{| class="wikitable"
| Sender || Entity wishing to transfer value that they control