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 B189B92 for ; Wed, 22 Jun 2016 20:11:48 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f174.google.com (mail-qk0-f174.google.com [209.85.220.174]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6B68916E for ; Wed, 22 Jun 2016 20:11:47 +0000 (UTC) Received: by mail-qk0-f174.google.com with SMTP id t127so81004347qkf.1 for ; Wed, 22 Jun 2016 13:11:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=2/00iIhDuznKpC5nxjHa8j9r1QZD2qFGASWITzqSQ7w=; b=pZFgW+WbYKsfAGRydXOHuZkL5JdVjq2DaqZgRfzwLXGF2pGpJZYuRwMENX7DHVxDCf 0FjB42vuM540eiIcOAnDvvs058aZF+Iq26MnoUI207WVdFuy5FVSGXchUUfiVdxH9Tyg 3AOuz/wJ8bIqDrcLmP/Ff1HmbCPVefwU8Oicr/dYupcmjTvseEDlpQxlXnC0T2mDcYej W/PFGMD5cBz13nWH/26EsgD+vZSUFm48McwezNAgiJSlGltx8fgzOGBsMRuCP/AsRjPL sHDPV7uJrCDSWmP/FAY7qdwPEdKI7plJ/5Xj3L61JX1lG0akK2hbqZSJUVuWdP4sQe+p nwQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=2/00iIhDuznKpC5nxjHa8j9r1QZD2qFGASWITzqSQ7w=; b=cnrKjWBrjkrFC1/BDfPrglQcdloNL/wh/Qv9wd1MHsEEU71cfWvuFk0qMJ4upy+SFp fxpL06E6HBleYSFGG2OushNf57sFiQC3QgSdzUU6wCA/tv1KK7noG88J+MIHhBHUkp2A X+5nfFxZ4LcolUerSCUwNrAWzeuRmG6vkSZzMR+lvC+BenMy9yLrjJN7XNBIPxIcgyID bp6g6RnE52lT5irv5OJU1ooz1qj82gSRXvPgEBSlzUtBqcqml5Ub+Xf7nBhfdW+Fw3xV 12kcFYmuTL3VT/sP5R/fPjx9ioSF9lBRbPwjqVOyqo6Sj56FhHwjsNHpbdXcT+v5b6NX /HgQ== X-Gm-Message-State: ALyK8tJMPYxwbRR9COnCX22/VZnfqfA1xTnZ3FIOsVwzzEeeaYoqOYiAwFAv+aQAv+dSw8szridEpwKxTdOXhQ== X-Received: by 10.200.57.40 with SMTP id s37mr39966848qtb.69.1466626306615; Wed, 22 Jun 2016 13:11:46 -0700 (PDT) MIME-Version: 1.0 References: <576A44F1.9050108@electrum.org> <576AAAC4.1020304@AndySchroder.com> <576ABAD6.7080308@AndySchroder.com> In-Reply-To: From: James MacWhyte Date: Wed, 22 Jun 2016 20:11:36 +0000 Message-ID: To: Erik Aronesty , Bitcoin Protocol Discussion , Andy Schroder Content-Type: multipart/alternative; boundary=001a1140aac206314a0535e38c10 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org 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 20:11:48 -0000 --001a1140aac206314a0535e38c10 Content-Type: text/plain; charset=UTF-8 Thomas, I like your idea about expanding Bitcoin URI's to include signatures. For BIP75 store and forward servers we are already thinking the DNS record would have the user's public key as well as the URL of their store and forward endpoint, so as soon as that becomes a standard you could use it just for the public key part. Expanding the Bitcoin URI should be done as well, for people who want to go the simpler route and not rely on servers. Erik, Andy, everyone else, I don't understand why subscriptions would need to be built into the protocol. With BIP75 the merchant could automatically issue a PaymentRequest message every X amount of time, and the customer's wallet would either display the request like normal or be set to pre-authorize requests from the merchant. If the merchant goes out of business, the requests would stop coming. This sounds like a UI issue and not a protocol-level requirement. If you think I'm wrong, please explain why :) On Wed, Jun 22, 2016 at 12:35 PM Erik Aronesty via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > - 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. >>> >> >> >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --001a1140aac206314a0535e38c10 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thomas,

I like your idea about expandin= g Bitcoin URI's to include signatures. For BIP75 store and forward serv= ers we are already thinking the DNS record would have the user's public= key as well as the URL of their store and forward endpoint, so as soon as = that becomes a standard you could use it just for the public key part. Expa= nding the Bitcoin URI should be done as well, for people who want to go the= simpler route and not rely on servers.

Erik, Andy= , everyone else,

I don't understand why subscr= iptions would need to be built into the protocol. With BIP75 the merchant c= ould automatically issue a PaymentRequest message every X amount of time, a= nd the customer's wallet would either display the request like normal o= r be set to pre-authorize requests from the merchant. If the merchant goes = out of business, the requests would stop coming. This sounds like a UI issu= e and not a protocol-level requirement.

If you think I'm wrong, = please explain why :)

= On Wed, Jun 22, 2016 at 12:35 PM Erik Aronesty via bitcoin-dev <bitcoin-dev@lists.linuxfo= undation.org> wrote:
- Payment channels seem clearly inappropriate for thing= s like monthly subscriptions, the use of nlocktime, etc.

- Mer= chants cannot send requests to users for future payments, because users don= 't run servers that they can connect to.=C2=A0 That's why BIP0070 w= orks the way it does.

- Need to have an interval for subs= criptions, at a minimum, and stored in the wallet so next months payment ca= n go out on time

- Support for varying currency conversion needs 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.



_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--001a1140aac206314a0535e38c10--