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 BF2759C for ; Wed, 22 Jun 2016 16:20:42 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from uschroder.com (uschroder.com [74.142.93.202]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 220F017B for ; Wed, 22 Jun 2016 16:20:42 +0000 (UTC) Received: from [192.168.253.4] (cpe-96-28-21-149.kya.res.rr.com [96.28.21.149]) by uschroder.com (Postfix) with ESMTPSA id 3DC96233B25AD; Wed, 22 Jun 2016 12:20:41 -0400 (EDT) To: Erik Aronesty References: <576A44F1.9050108@electrum.org> <576AAAC4.1020304@AndySchroder.com> From: Andy Schroder Openpgp: id=893F9F58D7AECF9DF0F772F534FAEFDB2D44186B; url=http://andyschroder.com/static/AndySchroder.asc Message-ID: <576ABAD6.7080308@AndySchroder.com> Date: Wed, 22 Jun 2016 12:20:38 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="V43DbUVN5405JSiChiA4EuIn4OKOf7reC" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 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:08 +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 16:20:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --V43DbUVN5405JSiChiA4EuIn4OKOf7reC Content-Type: multipart/mixed; boundary="CW7il04V0TjL6lP63vUTIdL6FCswtxrlE" From: Andy Schroder To: Erik Aronesty Cc: Bitcoin Protocol Discussion , Thomas Voegtlin Message-ID: <576ABAD6.7080308@AndySchroder.com> Subject: Re: Even more proposed BIP extensions to BIP 0070 References: <576A44F1.9050108@electrum.org> <576AAAC4.1020304@AndySchroder.com> In-Reply-To: --CW7il04V0TjL6lP63vUTIdL6FCswtxrlE Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable I understand the need for people to make repeated payments to=20 individuals in real life that they know, without the payee every even=20 taking the effort to make a formal payment request (say you're just=20 paying a family member of friend back for picking something up for you=20 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=20 about a model where service providers could deliver invoices, receipts,=20 and payment requests in a standardized and secure way. In addition to=20 having a send, receive, and transaction history tab in your bitcoin=20 wallet, you'd also have an open payment channels tab (which would=20 include all applications on your computer that have an open real time=20 payment channel, such as a wifi access point, web browser, voip=20 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=20 logging into a million different websites to get the bills and then pay=20 them. If it were this easy, why would you ever want to do a recurring=20 payment from a single payment request? I understand why you may think=20 you want to given current work flows, but I'm wondering if it may be=20 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,=20 > don't change a bit, and stick any subscription information (future=20 > payment schedule) in the PaymentACK. Then the wallet then=20 > re-initiates an invoice (unattended or attended.. up to the user),=20 > after the subscription interval is passed. Subscriptions are pretty=20 > important for Bitcoin to be used as a real payment system.=20 --CW7il04V0TjL6lP63vUTIdL6FCswtxrlE-- --V43DbUVN5405JSiChiA4EuIn4OKOf7reC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJXarrXAAoJEDT679stRBhrxCIH/imAZaiwPSvzSzbf203VYzMc z5CY63wDRHIa07CM0gv6Fzv19Tfiim54sFOkHMiSPMVJya2Edwji9CY025M2nUZJ uyPyRxowuXV9xsnUc+nRHzzaEfVC+DIuQFe5O0UQy9XFa4U3smxvGM5rWEw4iRuB eu1lDJ7434b/gcwsaRktc6o4ebdAK6dAapovpQR5VRqgcyZTgsEAspKb8X52YhBL +UpDNPWnCYezPR9CGBbWlrGarAMJ1xQ0s5vHh+uGpNt1riKfiL52QpQI8lFHoPfb oMGMzJ8N/2OCIxM1dZx5zwuJc4D6GYAjWKI7CAvKM6NfXNr34nJ5DkE40Cmj5Lo= =h9Ux -----END PGP SIGNATURE----- --V43DbUVN5405JSiChiA4EuIn4OKOf7reC--