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.