summaryrefslogtreecommitdiff
path: root/0a/6665bbb4c5047f2b786b6a89263466e7dd877d
blob: b053eb76e94ed176e3f8d0b5e570ea71e4e99116 (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
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
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 <jgarzik@bitpay.com>) id 1W80Wr-00010w-RV
	for bitcoin-development@lists.sourceforge.net;
	Tue, 28 Jan 2014 04:44:05 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of bitpay.com
	designates 74.125.82.43 as permitted sender)
	client-ip=74.125.82.43; envelope-from=jgarzik@bitpay.com;
	helo=mail-wg0-f43.google.com; 
Received: from mail-wg0-f43.google.com ([74.125.82.43])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1W80Wq-0003qS-Lm
	for bitcoin-development@lists.sourceforge.net;
	Tue, 28 Jan 2014 04:44:05 +0000
Received: by mail-wg0-f43.google.com with SMTP id y10so6915401wgg.10
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 27 Jan 2014 20:43:58 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=nZELM3PNviX0ivgmzlS4xq6FnSMSNQW7D/66VwXCeok=;
	b=E/PDffIJtYu8/oi7i6Yw/GbKQZO1xbCQHU+6o4BwzKeO7HfF1wlDiwY/hj/mYyXwm6
	426lO/X9TMGDiI4nbLkc9yGoj7/fYKcnOmEU2WKp5tmYrxhF0XY8XvkZyVztlZzQNw5d
	uVYrJLTClrOlKhUh85wzmmRK2KVxMUuDOjQIp+adGnKbxyxWUMe9JLuZVhmORSiIjczP
	WdCI2urT35IgosPlsRHgsItgKuBhN6KTMS8LlgU5JgZbbA/t9w6AsIHzol86NZaa1QQG
	f7mIEeWNfvGl/KkAYSfhe3cU9HkQY/IfBlHvsGDqYyvnYk9YBCu+8ofD8ESIvTW5J2Uz
	Z6KA==
X-Gm-Message-State: ALoCoQkDQZ/6OHCqwCrpfOhQXtO63p1fY58thKH0zL2TY3E94LSlWdgMMHR4U8DeB1ZGn93r5p3w
MIME-Version: 1.0
X-Received: by 10.180.182.226 with SMTP id eh2mr565878wic.36.1390884238355;
	Mon, 27 Jan 2014 20:43:58 -0800 (PST)
Received: by 10.194.2.164 with HTTP; Mon, 27 Jan 2014 20:43:58 -0800 (PST)
In-Reply-To: <E1FDB3F2-25ED-4B99-979E-12CE943CBD66@kill-bill.org>
References: <E1FDB3F2-25ED-4B99-979E-12CE943CBD66@kill-bill.org>
Date: Mon, 27 Jan 2014 23:43:58 -0500
Message-ID: <CAJHLa0NvufgU6NUKWR6a_foibtEVGSmpMjTB2_pqFhqrEGMssw@mail.gmail.com>
From: Jeff Garzik <jgarzik@bitpay.com>
To: Stephane Brossier <stephane@kill-bill.org>
Content-Type: multipart/alternative; boundary=089e016347f0f3811b04f1007876
X-Spam-Score: -0.6 (/)
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
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1W80Wq-0003qS-Lm
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
	Pierre-Alexandre Meyer <pierre@kill-bill.org>
Subject: Re: [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 04:44:06 -0000

--089e016347f0f3811b04f1007876
Content-Type: text/plain; charset=ISO-8859-1

Yes, recurring payments and subscriptions is a frequently-requested
feature.  It needs a new BIP.  Here is an outline:

The situation is somewhat analogous to HTML5 local storage.  The remote
(merchant) wants to initiate a persistent behavior.  This is bitcoin, so we
have a "push" model for payment, and the user has complete control.  The
merchant can, at most, send a "subscription request."  The user is
responsible for making on-time payments after that point.

Centralized services like coinbase.com or blockchain.info will have an easy
time of it.  An automated program on their backend, sending payments as
needed, is easy and direct.

More inventive services might employ multisig transactions, generating and
signing one signature of a TX, then sending that TX to the human for
further signing and publishing.  A few competing vendors could offer bots
that provide this signing service.

Decentralized, standalone wallet clients will be somewhat troublesome.  We
can store a local subscription request, and send recurring payments...  if
the wallet app is running.  If not, the user will be missing payments, that
perhaps they intended to make (rent!).

Each of these solutions can be cancelled at any time by the user.  As such,
a courtesy "subscription cancelled" message sent to the merchant is
recommended.  User controls the usage of their money at all times, the way
things should be.

And finally, you do not want to make it /too easy/ to send money over and
over again.  From a human-interface perspective, a textual reminder to send
money might be preferred over actual recurring payment automation: reminder
email + manual spend inserts a bit of additional human thought and review
into the process, with all that entails.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

--089e016347f0f3811b04f1007876
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>Yes, recurring payments and subscriptions i=
s a frequently-requested feature. =A0It needs a new BIP. =A0Here is an outl=
ine:<br><br>The situation is somewhat analogous to HTML5 local storage. =A0=
The remote (merchant) wants to initiate a persistent behavior.=A0 This is b=
itcoin, so we have a &quot;push&quot; model for payment, and the user has c=
omplete control.=A0 The merchant can, at most, send a &quot;subscription re=
quest.&quot;=A0 The user is responsible for making on-time payments after t=
hat point.<br>
<br>Centralized services like <a href=3D"http://coinbase.com">coinbase.com<=
/a> or <a href=3D"http://blockchain.info">blockchain.info</a> will have an =
easy time of it.=A0 An automated program on their backend, sending payments=
 as needed, is easy and direct.<br>
<br></div>More inventive services might employ multisig transactions, gener=
ating and signing one signature of a TX, then sending that TX to the human =
for further signing and publishing.=A0 A few competing vendors could offer =
bots that provide this signing service.<br>
<br></div>Decentralized, standalone wallet clients will be somewhat trouble=
some.=A0 We can store a local subscription request, and send recurring paym=
ents...=A0 if the wallet app is running.=A0 If not, the user will be missin=
g payments, that perhaps they intended to make (rent!).<br>
<br></div><div>Each of these solutions can be cancelled at any time by the =
user.=A0 As such, a courtesy &quot;subscription cancelled&quot; message sen=
t to the merchant is recommended.=A0 User controls the usage of their money=
 at all times, the way things should be.<br>
</div><div><br></div>And finally, you do not want to make it /too easy/ to =
send money over and over again.=A0 From a human-interface perspective, a te=
xtual reminder to send money might be preferred over actual recurring payme=
nt automation: reminder email + manual spend inserts a bit of additional hu=
man thought and review into the process, with all that entails.<br>
<div><div><div><br>-- <br>Jeff Garzik<br>Bitcoin core developer and open so=
urce evangelist<br>BitPay, Inc. =A0 =A0 =A0<a href=3D"https://bitpay.com/">=
https://bitpay.com/</a><br></div></div></div></div>

--089e016347f0f3811b04f1007876--