- 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 <i...@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. >> > > >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
