MIME-Version: 1.0
Sender: earonesty@gmail.com
In-Reply-To: <576ABAD6.7080308@AndySchroder.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>
	<576ABAD6.7080308@AndySchroder.com>
From: Erik Aronesty <erik@q32.com>
Date: Wed, 22 Jun 2016 13:07:21 -0400
Message-ID: <CAJowKgJMn5BDUUyQAU56XV-spUmy3GWHAieVEA9Nm9Y6ct7TNw@mail.gmail.com>
To: Andy Schroder <info@andyschroder.com>
Content-Type: multipart/alternative; boundary=001a11c05a548c569e0535e0f889
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070
Precedence: list

--001a11c05a548c569e0535e0f889
Content-Type: text/plain; charset=UTF-8

- Payment channels seem clearly inappropriate for things like monthly
subscriptions, the use of nlocktime, etc.

- Merchants cannot send requests to users for future payments, because
users don't run servers that they can connect to.  That's why BIP0070 works
the way it does.

- Need to have an interval for subscriptions, at a minimum, and stored in
the wallet so next months payment can go out on time

- Support for varying currency conversion needs to be baked in to
wallets.   Fortunately, by adding advisory subscription info to the
paymentrequest, this is left up to the wallet to
secure/validate/repeat/convert/etc. as needed for each subscription.

- The UI you describe is nice - but not unique to the solution.


On Wed, Jun 22, 2016 at 12:20 PM, Andy Schroder <info@andyschroder.com>
wrote:

> I understand the need for people to make repeated payments to individuals
> in real life that they know, without the payee every even taking the effort
> to make a formal payment request (say you're just paying a family member of
> friend back for picking something up for you 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 about a
> model where service providers could deliver invoices, receipts, and payment
> requests in a standardized and secure way. In addition to having a send,
> receive, and transaction history tab in your bitcoin wallet, you'd also
> have an open payment channels tab (which would include all applications on
> your computer that have an open real time payment channel, such as a wifi
> access point, web browser, voip 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 logging into a million different websites to get
> the bills and then pay them. If it were this easy, why would you ever want
> to do a recurring payment from a single payment request? I understand why
> you may think you want to given current work flows, but I'm wondering if it
> may be 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,
>> don't change a bit, and stick any subscription information (future payment
>> schedule) in the PaymentACK.   Then the wallet then re-initiates an invoice
>> (unattended or attended.. up to the user), after the subscription interval
>> is passed. Subscriptions are pretty important for Bitcoin to be used as a
>> real payment system.
>>
>
>
>

--001a11c05a548c569e0535e0f889
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>- Payment channels seem clearly inappropriate fo=
r things like monthly subscriptions, the use of nlocktime, etc.<br><br></di=
v>- Merchants cannot send requests to users for future payments, because us=
ers don&#39;t run servers that they can connect to.=C2=A0 That&#39;s why BI=
P0070 works the way it does.<br><br></div><div>- Need to have an interval f=
or subscriptions, at a minimum, and stored in the wallet so next months pay=
ment can go out on time<br><br>- Support for varying currency conversion ne=
eds to be baked in to=20
wallets.=C2=A0=C2=A0 Fortunately, by adding advisory subscription info to t=
he=20
paymentrequest, this is left up to the wallet to secure/validate/repeat/con=
vert/etc.=20
as needed for each subscription.<br><br></div><div>- The UI you describe is=
 nice - but not unique to the solution.<br></div><div><br><br><br></div></d=
iv><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Jun 22=
, 2016 at 12:20 PM, Andy Schroder <span dir=3D"ltr">&lt;<a href=3D"mailto:i=
nfo@andyschroder.com" target=3D"_blank">info@andyschroder.com</a>&gt;</span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">I understand the need for people=
 to make repeated payments to individuals in real life that they know, with=
out the payee every even taking the effort to make a formal payment request=
 (say you&#39;re just paying a family member of friend back for picking som=
ething up for you at the store, and you&#39;ve already payed them many time=
s before).<br>
<br>
For a subscription, wouldn&#39;t it be better to promote payment channels o=
r just send another payment request? I&#39;ve been brainstorming recently a=
bout a model where service providers could deliver invoices, receipts, and =
payment requests in a standardized and secure way. In addition to having a =
send, receive, and transaction history tab in your bitcoin wallet, you&#39;=
d also have an open payment channels tab (which would include all applicati=
ons on your computer that have an open real time payment channel, such as a=
 wifi access point, web browser, voip provider, etc.), as well as a &quot;b=
ills to pay&quot; tab. Since everything would be automated and consolidated=
 locally, you wouldn&#39;t have to deal with logging into a million differe=
nt websites to get the bills and then pay them. If it were this easy, why w=
ould you ever want to do a recurring payment from a single payment request?=
 I understand why you may think you want to given current work flows, but I=
&#39;m wondering if it may be better to just skip over to a completely bett=
er way of doing things.<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
<br>
Andy Schroder</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
On 06/22/2016 11:30 AM, Erik Aronesty wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
My conclusion at the bottom of that post was to keep BIP 75 the same, don&#=
39;t change a bit, and stick any subscription information (future payment s=
chedule) in the PaymentACK.=C2=A0 =C2=A0Then the wallet then re-initiates a=
n invoice (unattended or attended.. up to the user), after the subscription=
 interval is passed. Subscriptions are pretty important for Bitcoin to be u=
sed as a real payment system. <br>
</blockquote>
<br>
<br>
</div></div></blockquote></div><br></div>

--001a11c05a548c569e0535e0f889--