From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 3CA3C92 for ; Wed, 22 Jun 2016 17:07:24 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-yw0-f171.google.com (mail-yw0-f171.google.com [209.85.161.171]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 47ACC8E for ; Wed, 22 Jun 2016 17:07:23 +0000 (UTC) Received: by mail-yw0-f171.google.com with SMTP id l125so47849078ywb.2 for ; Wed, 22 Jun 2016 10:07:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=MYuZqrJWOMkvw8u1OJSXeIwdwErAbInBsyT1nFQwGf4=; b=F5x4GhQbJDPJeQW8fsEJtMylAqfu1GtwECHxuiCXPUSdmoiqxJ8jWJNEQntffzdYjk DEuGg0/QGM3Yw9M5WsGFG6iAWzDqSSv0OgpnIOrtZ+LVxPDn83knqmVfriR/eQPBhLZo a9J+/RRIc9qJeC4x39MBFaXzVAUv2V9mZEwKlzBHrvecr/M0M03eBdcxLN0Ono7/uKoa BWGJu/Pkv3o8p1Vm4UU8jCdDYGT3te0WaxcjIbmi9HnITSew5PrW8gFLXZG5DwgIrXKw m9/MnB9/vTU8Jc8mjzWBoXP5OJmHWcoKmQ9gFw5ID4NvW8ehcqhYDUmqYFjRW18Ora3x SmBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=MYuZqrJWOMkvw8u1OJSXeIwdwErAbInBsyT1nFQwGf4=; b=jlbrEbOJK7kpSwOfDjR06SbixszdHEMxHTS8fqBEi6dHUWQ+23jfN5gZKVGXiImdRb X8/VfW6NXHv2K6vh1h4f6lrLA/lISw5Z1ehmT7TzDotopXdUw8PJXvpINAcZASQIr6TR EmAKU8wl8CYkvARku6HezzbSQvHjUzPOhzBFlRHOnh+M3yxpOFIXuQULQrCuyvwvQC3S 025srdy564yIBAsS2SdDSD9K2Ovk6ByvkWj+9rnp3CkfZOc66weJNqI+HBQeGaPD6ARL C00qfV0HUgX0d5ebtjwhBYs2aGm5fT3c4FjhsxZZXOzr90SGMlUWwf+NktldGHMVCvlr wuDw== X-Gm-Message-State: ALyK8tIjNv6YFYSeXWcyJ4AWqysvLSWqyzpFf9oPHs5MyiVH4Wj6OF5clB2cMjUDowUq6ynkN6Ohrvl1TM9BgQ== X-Received: by 10.37.65.144 with SMTP id o138mr15093205yba.87.1466615242443; Wed, 22 Jun 2016 10:07:22 -0700 (PDT) MIME-Version: 1.0 Sender: earonesty@gmail.com Received: by 10.37.72.68 with HTTP; Wed, 22 Jun 2016 10:07:21 -0700 (PDT) In-Reply-To: <576ABAD6.7080308@AndySchroder.com> References: <576A44F1.9050108@electrum.org> <576AAAC4.1020304@AndySchroder.com> <576ABAD6.7080308@AndySchroder.com> From: Erik Aronesty Date: Wed, 22 Jun 2016 13:07:21 -0400 X-Google-Sender-Auth: YK0P_a5J1Q4vnPCJ-gI_7XLdpQI Message-ID: To: Andy Schroder Content-Type: multipart/alternative; boundary=001a11c05a548c569e0535e0f889 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Wed, 22 Jun 2016 19:34:13 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 17:07:24 -0000 --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 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
- Payment channels seem clearly inappropriate fo= r things like monthly subscriptions, the use of nlocktime, etc.

- Merchants cannot send requests to users for future payments, because us= ers don't run servers that they can connect to.=C2=A0 That's why BI= P0070 works the way it does.

- 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

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

- 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, with= out 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 som= ething up for you at the store, and you've already payed them many time= s before).

For a subscription, wouldn't it be better to promote payment channels o= r just send another payment request? I'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'= 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 "b= ills to pay" tab. Since everything would be automated and consolidated= locally, you wouldn'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= 'm wondering if it may be better to just skip over to a completely bett= er 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&#= 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.



--001a11c05a548c569e0535e0f889--