- 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.
>>
>
>
>