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
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <stephane@kill-bill.org>) id 1W7yXb-0004NE-U9
for bitcoin-development@lists.sourceforge.net;
Tue, 28 Jan 2014 02:36:43 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of kill-bill.org
designates 209.85.160.41 as permitted sender)
client-ip=209.85.160.41; envelope-from=stephane@kill-bill.org;
helo=mail-pb0-f41.google.com;
Received: from mail-pb0-f41.google.com ([209.85.160.41])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1W7yXa-0006C6-O8
for bitcoin-development@lists.sourceforge.net;
Tue, 28 Jan 2014 02:36:43 +0000
Received: by mail-pb0-f41.google.com with SMTP id up15so6700396pbc.0
for <bitcoin-development@lists.sourceforge.net>;
Mon, 27 Jan 2014 18:36:36 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:from:content-type:subject:date:message-id:cc:to
:mime-version;
bh=kkkbWw2VUfDKcLekIwgQRggzc/rJATE000jmisTmU4w=;
b=jkoeOcFiMjcqJd2G5alTepvvftdBb5Q6dZ9EkiIoDsv4WOuI79ZqGs7FhVRmel/6aK
rN3y5C+zTjt3LtS7udwJn7q37a4BS5lRmX8CRQ/Kvvznm630i4QJPe4egtdYC80uAET0
EnXi9/ShqQFYeAZzmqq5NlxlJMlLt9/scuQJXp3T28DREBCaqxLJoHReY0C+Un696IyO
EwpANQ6/6WNVI2/rNWRjaxBmDqvYZXJ1q5tm8P5dY9CRugX21NMGPTC7N+LdAf36w2DY
3SV6ILKFMXvV3FlKyMxLiqDZvAefxcx912Fc9x5Gc3frwkoSQOgnlt90RZKFE1Hk+bCR
Ryyg==
X-Gm-Message-State: ALoCoQns05gKsO7BDOxHL0U2iC+sr7pYpDTqLG8TwOsJtuwfsm63RvkyGG/NMdSgLsAbMmuP0Ns+
X-Received: by 10.68.245.200 with SMTP id xq8mr33525020pbc.21.1390876596684;
Mon, 27 Jan 2014 18:36:36 -0800 (PST)
Received: from [192.168.1.104] (adsl-71-146-11-192.dsl.pltn13.sbcglobal.net.
[71.146.11.192]) by mx.google.com with ESMTPSA id
yi8sm98642553pab.16.2014.01.27.18.36.35 for <multiple recipients>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Mon, 27 Jan 2014 18:36:36 -0800 (PST)
From: Stephane Brossier <stephane@kill-bill.org>
Content-Type: multipart/alternative;
boundary="Apple-Mail=_AEE5C524-FAD1-4F64-AE6E-37E17B20C6FA"
Date: Mon, 27 Jan 2014 18:36:34 -0800
Message-Id: <E1FDB3F2-25ED-4B99-979E-12CE943CBD66@kill-bill.org>
To: bitcoin-development@lists.sourceforge.net
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
X-Mailer: Apple Mail (2.1510)
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1W7yXa-0006C6-O8
Cc: "stephane@kill-bill.org" <stephane@kill-bill.org>,
Pierre-Alexandre Meyer <pierre@kill-bill.org>
Subject: [Bitcoin-development] Extension for BIP-0070 to support recurring
payments
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 28 Jan 2014 02:36:44 -0000
--Apple-Mail=_AEE5C524-FAD1-4F64-AE6E-37E17B20C6FA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=iso-8859-1
Hi,
[I sent this email 2 days ago prior my registration to the mailing list; =
please forgive me if this is a duplicate]
I would like to propose an extension to the Payment Protocol (bip-0070) =
to address the case of recurring payments in Bitcoin -- new bip or =
modification of bip-0070.
There has been a lot of growth in the last few years in the =
'subscription economy' with many new companies embracing that model -- =
online video, gaming, groceries, newspapers,... In parallel, Bitcoin is =
growing into a mainstream currency (hence bip-0070), and so the next =
logical step would be to define a protocol to address that need.
We have been working in the past few years on an open-source billing =
platform (http://kill-bill.org/), and recently came with a prototype to =
do recurring billing in Bitcoin (see =
http://thekillbillstory.wordpress.com/2014/01/20/bitcoin-plugin/ and =
http://thekillbillstory.wordpress.com/2014/01/11/coinbase-integration-expe=
riment/).
The work flow would look similar to the one from bip-0070. There would =
need to be some additions; the flow could be summarized as follow:
0. Click: 'Subscribe Now'
1. Wallet would get a RecurringPaymentRequestAuth which describes the =
nature of the future recurring payments
2. The Customer would get prompted from the wallet to authorize it.
3. The wallet would then poll the Merchant server (startup time, and/or =
well defined frequency) and potentially merchant would start issuing a =
PaymentRequest); the role of the wallet is to ensure that PaymentRequest =
is within the bounds of what was accepted by the customer-- amount, =
frequency,.. If it is, then it would make the Payment the same way it =
works for bip-0070
Is that something that the community would be interested in? We could =
provide more details about the protocol we have in mind (messages and =
flow), and also provide an implementation with bitcoinj as a wallet and =
Kill Bill as a merchant server.
Le me know what you think.
St=E9phane=
--Apple-Mail=_AEE5C524-FAD1-4F64-AE6E-37E17B20C6FA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=iso-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Diso-8859-1"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><div>Hi,</div><div><div><br></div><div>[I sent this email 2 days ago =
prior my registration to the mailing list; please forgive me if this is =
a duplicate]</div><div><br></div><div>I would like to propose an =
extension to the Payment Protocol (bip-0070) to address the case of =
recurring payments in Bitcoin -- new bip or modification =
of bip-0070.</div><div><br></div><div>There has been a lot of =
growth in the last few years in the 'subscription economy' with many new =
companies embracing that model -- online video, gaming, groceries, =
newspapers,... In parallel, Bitcoin is growing into a mainstream =
currency (hence bip-0070), and so the next logical step would be to =
define a protocol to address that need.</div><div><br></div><div>We have =
been working in the past few years on an open-source billing platform =
(<a href=3D"http://kill-bill.org/">http://kill-bill.org/</a>), and =
recently came with a prototype to do recurring billing in Bitcoin =
(see <a =
href=3D"http://thekillbillstory.wordpress.com/2014/01/20/bitcoin-plugin/">=
http://thekillbillstory.wordpress.com/2014/01/20/bitcoin-plugin/</a> =
and <a =
href=3D"http://thekillbillstory.wordpress.com/2014/01/11/coinbase-integrat=
ion-experiment/">http://thekillbillstory.wordpress.com/2014/01/11/coinbase=
-integration-experiment/</a>).</div><div><br></div><div><br></div><div>The=
work flow would look similar to the one from bip-0070. There would need =
to be some additions; the flow could be summarized as =
follow:</div><div><br></div><div>0. Click: 'Subscribe Now'</div><div>1. =
Wallet would get a RecurringPaymentRequestAuth which describes the =
nature of the future recurring payments</div><div>2. The Customer would =
get prompted from the wallet to authorize it.</div><div>3. The wallet =
would then poll the Merchant server (startup time, and/or well defined =
frequency) and potentially merchant would start issuing a =
PaymentRequest); the role of the wallet is to ensure that PaymentRequest =
is within the bounds of what was accepted by the customer-- amount, =
frequency,.. If it is, then it would make the Payment the same way it =
works for bip-0070</div><div><br></div><div>Is that something that the =
community would be interested in? We could provide more details about =
the protocol we have in mind (messages and flow), and also provide an =
implementation with bitcoinj as a wallet and Kill Bill as a merchant =
server.</div><div><br></div><div>Le me know what you =
think.</div><div><br></div><div>St=E9phane</div></div></body></html>=
--Apple-Mail=_AEE5C524-FAD1-4F64-AE6E-37E17B20C6FA--
|
