To: Erik Aronesty <erik@q32.com>
References: <CAJowKg+zYtUnHv+ea--srehVa5K46sjpWbHVcVGRY5x0w5XRTQ@mail.gmail.com>
	<576A44F1.9050108@electrum.org>
	<CAJowKgLTtPKCV_6YWdTU2DiF0CAAiouggfGYVA+cax0Fyzc9Mg@mail.gmail.com>
	<576AAAC4.1020304@AndySchroder.com>
	<CAJowKgLK=AbsXcfsRKWNRQ=N=0QC3EVsALWxw6UOMCUXPo70fA@mail.gmail.com>
From: Andy Schroder <info@AndySchroder.com>
Openpgp: id=893F9F58D7AECF9DF0F772F534FAEFDB2D44186B;
	url=http://andyschroder.com/static/AndySchroder.asc
Message-ID: <576ABAD6.7080308@AndySchroder.com>
Date: Wed, 22 Jun 2016 12:20:38 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
	Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <CAJowKgLK=AbsXcfsRKWNRQ=N=0QC3EVsALWxw6UOMCUXPo70fA@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="V43DbUVN5405JSiChiA4EuIn4OKOf7reC"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070
Precedence: list

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--V43DbUVN5405JSiChiA4EuIn4OKOf7reC
Content-Type: multipart/mixed; boundary="CW7il04V0TjL6lP63vUTIdL6FCswtxrlE"
From: Andy Schroder <info@AndySchroder.com>
To: Erik Aronesty <erik@q32.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Thomas Voegtlin <thomasv@electrum.org>
Message-ID: <576ABAD6.7080308@AndySchroder.com>
Subject: Re: Even more proposed BIP extensions to BIP 0070
References: <CAJowKg+zYtUnHv+ea--srehVa5K46sjpWbHVcVGRY5x0w5XRTQ@mail.gmail.com>
 <576A44F1.9050108@electrum.org>
 <CAJowKgLTtPKCV_6YWdTU2DiF0CAAiouggfGYVA+cax0Fyzc9Mg@mail.gmail.com>
 <576AAAC4.1020304@AndySchroder.com>
 <CAJowKgLK=AbsXcfsRKWNRQ=N=0QC3EVsALWxw6UOMCUXPo70fA@mail.gmail.com>
In-Reply-To: <CAJowKgLK=AbsXcfsRKWNRQ=N=0QC3EVsALWxw6UOMCUXPo70fA@mail.gmail.com>

--CW7il04V0TjL6lP63vUTIdL6FCswtxrlE
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

I understand the need for people to make repeated payments to=20
individuals in real life that they know, without the payee every even=20
taking the effort to make a formal payment request (say you're just=20
paying a family member of friend back for picking something up for you=20
at the store, and you've already payed them many times before).

For a subscription, wouldn't it be better to promote payment channels or =

just send another payment request? I've been brainstorming recently=20
about a model where service providers could deliver invoices, receipts,=20
and payment requests in a standardized and secure way. In addition to=20
having a send, receive, and transaction history tab in your bitcoin=20
wallet, you'd also have an open payment channels tab (which would=20
include all applications on your computer that have an open real time=20
payment channel, such as a wifi access point, web browser, voip=20
provider, etc.), as well as a "bills to pay" tab. Since everything would =

be automated and consolidated locally, you wouldn't have to deal with=20
logging into a million different websites to get the bills and then pay=20
them. If it were this easy, why would you ever want to do a recurring=20
payment from a single payment request? I understand why you may think=20
you want to given current work flows, but I'm wondering if it may be=20
better to just skip over to a completely better way of doing things.


Andy Schroder

On 06/22/2016 11:30 AM, Erik Aronesty wrote:
> My conclusion at the bottom of that post was to keep BIP 75 the same,=20
> don't change a bit, and stick any subscription information (future=20
> payment schedule) in the PaymentACK.   Then the wallet then=20
> re-initiates an invoice (unattended or attended.. up to the user),=20
> after the subscription interval is passed. Subscriptions are pretty=20
> important for Bitcoin to be used as a real payment system.=20


--CW7il04V0TjL6lP63vUTIdL6FCswtxrlE--

--V43DbUVN5405JSiChiA4EuIn4OKOf7reC
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJXarrXAAoJEDT679stRBhrxCIH/imAZaiwPSvzSzbf203VYzMc
z5CY63wDRHIa07CM0gv6Fzv19Tfiim54sFOkHMiSPMVJya2Edwji9CY025M2nUZJ
uyPyRxowuXV9xsnUc+nRHzzaEfVC+DIuQFe5O0UQy9XFa4U3smxvGM5rWEw4iRuB
eu1lDJ7434b/gcwsaRktc6o4ebdAK6dAapovpQR5VRqgcyZTgsEAspKb8X52YhBL
+UpDNPWnCYezPR9CGBbWlrGarAMJ1xQ0s5vHh+uGpNt1riKfiL52QpQI8lFHoPfb
oMGMzJ8N/2OCIxM1dZx5zwuJc4D6GYAjWKI7CAvKM6NfXNr34nJ5DkE40Cmj5Lo=
=h9Ux
-----END PGP SIGNATURE-----

--V43DbUVN5405JSiChiA4EuIn4OKOf7reC--