mirrors/bitcoin-bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2024-11-19 01:40:05 +01:00
Code Issues Projects Releases Wiki Activity

- Update e-mail addresses for Justin and Matt

Browse Source 
- Add 2 new use cases and add Wallet Name to the Address Book section of optional ways to add entries to an address book
This commit is contained in:
Matt David 2016-02-10 09:43:21 -08:00
parent 06c3c1b488
commit 7ae2624bb3
1 changed files with 36 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

41
bip-invoicerequest-extension.mediawiki
View File

@ -1,8 +1,8 @@
<pre>
BIP: XXX
Title: Out of Band Address Exchange using Encrypted PaymentRequests
Authors: Matt David <matt@netki.com>
Justin Newton <justin@netki.com>
Authors: Justin Newton <justin@gid.net>
Matt David <mgd@mgddev.com>
Aaron Voisine <voisine@gmail.com>
James MacWhyte <macwhyte@gmail.com>
Status: Draft
@ -39,11 +39,42 @@ The motivation for this extension to BIP70 is twofold:
In short we wanted to make bitcoin more human, while at the same time improving transaction privacy.
==Example Use Case==
==Example Use Cases==
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.
# Address Book
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.
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 using a Wallet Name, 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.
# 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
to a new potential sending party only if they can confirm the identity of the potential sending party. BIP70 specifies that
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.
With this BIP, Bitcoin wallets could prompt a wallet user to release payment information while displaying identity
information about the potential sending party via an included certificate. This allows the potential receiving party to
make a more informed decision regarding to whom they are releasing payment and identity information.
# Using Store & Forward Servers
Let's say a Bitcoin wallet developer would like to use a public Store & Forward service for an asynchronous address
exchange. This is a common case for mobile and offline wallets.
With this BIP, returned payment information is encrypted with an ECDH-computed shared key before sending to a Store & Forward
service. In this case, a successful attack against a Store & Forward service would not be able to read or modify wallet address
or payment information, only delete encrypted messages.
==Definitions==
{| class="wikitable"