summaryrefslogtreecommitdiff
path: root/51/cf8687edf0338bb1d451f572b537589fedd4e9
blob: 464d3f2b72c441fe309d9e033d1f6839da413b89 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
Return-Path: <luke@dashjr.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 0DF79E87
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  8 Mar 2016 22:35:14 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21])
	by smtp1.linuxfoundation.org (Postfix) with ESMTP id 99162156
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  8 Mar 2016 22:35:13 +0000 (UTC)
Received: from ishibashi.localnet (unknown
	[IPv6:2001:470:5:265:61b6:56a6:b03d:28d6])
	(Authenticated sender: luke-jr)
	by zinan.dashjr.org (Postfix) with ESMTPSA id 5328D38A2C8C;
	Tue,  8 Mar 2016 22:34:15 +0000 (UTC)
X-Hashcash: 1:25:160308:bitcoin-dev@lists.linuxfoundation.org::LQV4cxluRoDG4flm:brSuy
X-Hashcash: 1:25:160308:justin@netki.com::KE1es8RQEDp58sG4:giW9A
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org,
 Justin Newton <justin@netki.com>
Date: Tue, 8 Mar 2016 22:34:13 +0000
User-Agent: KMail/1.13.7 (Linux/4.1.18-gentoo; KDE/4.14.8; x86_64; ; )
References: <CABqynx+gGnJ2AVByr1eKueSaohHtJVFsAVKrfS94StW2NzLWjw@mail.gmail.com>
In-Reply-To: <CABqynx+gGnJ2AVByr1eKueSaohHtJVFsAVKrfS94StW2NzLWjw@mail.gmail.com>
X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
X-PGP-Key-ID: BD02942421F4889F
X-PGP-Keyserver: hkp://pgp.mit.edu
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201603082234.14398.luke@dashjr.org>
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Tue, 08 Mar 2016 22:54:29 +0000
Subject: Re: [bitcoin-dev] Proposed BIP extension to BIP 0070
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Mar 2016 22:35:14 -0000
X-List-Received-Date: Tue, 08 Mar 2016 22:35:14 -0000

Is there a way for Joe Mobile Wallet User to upload a set of N PaymentRequests 
authenticated by his key to an untrusted server, which encrypts and passes 
them on in response to InvoiceRequests? Or does this necessarily require the 
recipient to be online?

On Tuesday, March 01, 2016 6:58:16 PM Justin Newton via bitcoin-dev wrote:
> The following draft BIP proposes an update to the Payment Protocol.
> 
> Motivation:
> 
> 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.
> 
> The motivation for this extension to BIP70 is threefold:
> 
> 1. Ensure that the payment details can only be seen by the participants in
> the transaction, and not by any third party.
> 2. 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.
> 3. 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
>         * 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
> 
> In short we wanted to make bitcoin more human, while at the same time
> improving transaction privacy.
> 
> Full proposal here:
> 
> https://github.com/techguy613/bips/blob/master/bip-invoicerequest-extension
> .mediawiki
> 
> We look forward to your thoughts and feedback on this proposal!
> 
> Justin