Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of riseup.net
	designates 198.252.153.129 as permitted sender)
	client-ip=198.252.153.129;
	envelope-from=odinn.cyberguerrilla@riseup.net;
	helo=mx1.riseup.net; 
Message-ID: <ffaba6419d12b997feb1f421538d3b0b.squirrel@fulvetta.riseup.net>
In-Reply-To: <CAJHLa0NvufgU6NUKWR6a_foibtEVGSmpMjTB2_pqFhqrEGMssw@mail.gmail.com>
References: <E1FDB3F2-25ED-4B99-979E-12CE943CBD66@kill-bill.org>
	<CAJHLa0NvufgU6NUKWR6a_foibtEVGSmpMjTB2_pqFhqrEGMssw@mail.gmail.com>
Date: Mon, 27 Jan 2014 22:08:43 -0800
From: "Odinn Cyberguerrilla" <odinn.cyberguerrilla@riseup.net>
To: "Jeff Garzik" <jgarzik@bitpay.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Importance: Normal
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
	Stephane Brossier <stephane@kill-bill.org>,
	Pierre-Alexandre Meyer <pierre@kill-bill.org>
Subject: Re: [Bitcoin-development] Extension for BIP-0070 to support
 recurring payments
Precedence: list

Greatly appreciate seeing this discussion occur.  This is something that
potentially could be supported through a bounty - possibly a process BIP?

Possibly related: https://gist.github.com/ABISprotocol/8515891

> 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, s=
o
> we
> have a "push" model for payment, and the user has complete control.  Th=
e
> 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 bo=
ts
> 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 a=
nd
> 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 revi=
ew
> into the process, with all that entails.
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc.      https://bitpay.com/
> -----------------------------------------------------------------------=
-------
> WatchGuard Dimension instantly turns raw network data into actionable
> security intelligence. It gives you real-time visual feedback on key
> security issues and trends.  Skip the complicated setup - simply import
> a virtual appliance and go from zero to informed in seconds.
> http://pubads.g.doubleclick.net/gampad/clk?id=3D123612991&iu=3D/4140/os=
tg.clktrk_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>