path: root/e3/ae16316e21e757502f2696a77ebceab16d9701

Return-Path: <earonesty@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 305FA92
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 22 Jun 2016 20:37:10 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yw0-f170.google.com (mail-yw0-f170.google.com
	[209.85.161.170])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CA758122
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 22 Jun 2016 20:37:08 +0000 (UTC)
Received: by mail-yw0-f170.google.com with SMTP id i12so52241021ywa.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 22 Jun 2016 13:37:08 -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=5fnAmsk3vnKBj3+jVRUjRYgejFKRifwGa28Jh1q7f/Q=;
	b=oL1rDc7IzaEiTyE42ohuwBthMSHEG5aHgLXamgCZs5PrZ992D3CsxxNRRLucd4DTRs
	NOFxV9Sn3Qjfspua3mBhq+L4F6Fr8mIFdj1YyYpj5S1f30OVjzW71TELMu41/xJ3Gdio
	5GhI/+BAl1Sc5gI/7qlC3itv6jyE8YxTmzP3g6WulNtbzLQg9Mz501zlfp49AFHRg2+X
	LkmZXUIHZZEA79IolicaqGYwJz/5Fqi4vnzBfOAOY4CS9KvOOcG4ukyaer5j9SL5xQ1n
	g0nIYRsdN0X61vcZ2lI/PGDtI5aRPosG8PSjCYwlnytKRYbAwSY9Y1kNT8ErO+J01TKs
	iXCQ==
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=5fnAmsk3vnKBj3+jVRUjRYgejFKRifwGa28Jh1q7f/Q=;
	b=N0X7dug0GiEMLyp2iP0NH1nPvLRbpMdqFfccl3iWnMD79hHIq92NZBZb9nDufTTjnE
	ZsztK49N9pkjzrXIHOpG6Cd9/SCcLKzvt0243+u/Qs50cChD2maq33JcSqICDj87yl5D
	G7DaH4UBZRa4fRtv8iH75+37Vu5qkFw4SgNvjdIVm4hAkQtLVQubYvNnLvu2ytbo/zGE
	adcFWWAoN4TP4YPg5xx2jRiQr8souoLRYOFFQDJ8tfjzvkFpSKY4jhZl1cHboJrM9mqY
	TrfULV1DiFG2ycZAA3fRT4r+A4Xa/1p/xYHACgRnmUNWWC8Lrxv3wVwLzFQWJwioZn+n
	mVSg==
X-Gm-Message-State: ALyK8tKO2BaF7ysodF2ZC+7stslvqIzs6Vd6vmb3BxoM/z2m+XvomN/B4r0TIWvOaX3KEWbjszHB9ioXYbHPEQ==
X-Received: by 10.129.51.137 with SMTP id z131mr18309893ywz.52.1466627827932; 
	Wed, 22 Jun 2016 13:37:07 -0700 (PDT)
MIME-Version: 1.0
Sender: earonesty@gmail.com
Received: by 10.37.72.68 with HTTP; Wed, 22 Jun 2016 13:37:06 -0700 (PDT)
In-Reply-To: <CAH+Axy7WqFRrfi4HbtovDAa9pKfpPrvUWUSn4vZORqLjz_0YaQ@mail.gmail.com>
References: <CAJowKg+zYtUnHv+ea--srehVa5K46sjpWbHVcVGRY5x0w5XRTQ@mail.gmail.com>
	<576A44F1.9050108@electrum.org>
	<CAJowKgLTtPKCV_6YWdTU2DiF0CAAiouggfGYVA+cax0Fyzc9Mg@mail.gmail.com>
	<576AAAC4.1020304@AndySchroder.com>
	<CAJowKgLK=AbsXcfsRKWNRQ=N=0QC3EVsALWxw6UOMCUXPo70fA@mail.gmail.com>
	<576ABAD6.7080308@AndySchroder.com>
	<CAJowKgJMn5BDUUyQAU56XV-spUmy3GWHAieVEA9Nm9Y6ct7TNw@mail.gmail.com>
	<CAH+Axy7WqFRrfi4HbtovDAa9pKfpPrvUWUSn4vZORqLjz_0YaQ@mail.gmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Wed, 22 Jun 2016 16:37:06 -0400
X-Google-Sender-Auth: G52cyvzsweht_rpEVXN6NJHfSKE
Message-ID: <CAJowKgL2O44=UUg3h_-MqEEy3cHc+EhQPE3ivpxyyMN3VCLNDA@mail.gmail.com>
To: James MacWhyte <macwhyte@gmail.com>
Content-Type: multipart/alternative; boundary=001a11407346b3a9100535e3e6e5
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
Cc: Andy Schroder <info@andyschroder.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jun 2016 20:37:10 -0000

--001a11407346b3a9100535e3e6e5
Content-Type: text/plain; charset=UTF-8

> I don't understand why subscriptions would need to be built into the
protocol.

Simple: Because the PaymentRequest is somewhat counter-intuitively a
/response/ to a customer initiated action.   It's not something the
merchant can initiate (of course, logically this makes sense... how can a
merchant know how to connect to some random android app).

Customers initiate all InvoiceRequests  BIP0075 clarifies this.   BIP0070
merely says that the customer "somehow indicates they are ready to pay".
BIP0075 formalizes a standard way to do this.

In no way do merchants initiate anything (of course).   Subscription
information must reside in the customers wallet, in response to a
merchant's advice to set up subscription.   Tacking parameters on to a
PaymentRequest or PaymentAck is the only good way to do this within BIP
70/75.

The only thing to hash out is exactly what fields to tack on and what they
mean.  ( subscription amount / currency / interval / interval_type ...
can't think of anything else )

Wallets are responsible for initiating the subscriptions on behalf of the
user.  Recommendations on how to do this should go into the spec.

Of course any wallet can, with BIP0075 add support for subscriptions
without any spec - just let the user set them up manually.   But it would
be nice if a user didn't have to enter the main parameters for
subscriptions... too easy to get times amounts, etc wrong.


On Wed, Jun 22, 2016 at 4:11 PM, James MacWhyte <macwhyte@gmail.com> wrote:

> 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 <info@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
>>
>

--001a11407346b3a9100535e3e6e5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div><div>&gt; I don&#39;t understand why s=
ubscriptions would need to be built into the protocol.<br><br></div>Simple:=
 Because the PaymentRequest is somewhat counter-intuitively a /response/ to=
 a customer initiated action.=C2=A0=C2=A0 It&#39;s not something the mercha=
nt can initiate (of course, logically this makes sense... how can a merchan=
t know how to connect to some random android app).=C2=A0=C2=A0 <br><br>Cust=
omers initiate all InvoiceRequests=C2=A0 BIP0075 clarifies this.=C2=A0=C2=
=A0 BIP0070 merely says that the customer &quot;somehow indicates they are =
ready to pay&quot;.=C2=A0=C2=A0 BIP0075 formalizes a standard way to do thi=
s.<br><br></div>In no way do merchants initiate anything (of course).=C2=A0=
=C2=A0 Subscription information must reside in the customers wallet, in res=
ponse to a merchant&#39;s advice to set up subscription.=C2=A0=C2=A0 Tackin=
g parameters on to a PaymentRequest or PaymentAck is the only good way to d=
o this within BIP 70/75.=C2=A0 <br><br></div>The only thing to hash out is =
exactly what fields to tack on and what they mean.=C2=A0 ( subscription amo=
unt / currency / interval / interval_type ... can&#39;t think of anything e=
lse )<br></div><br></div>Wallets are responsible for initiating the subscri=
ptions on behalf of the user.=C2=A0 Recommendations on how to do this shoul=
d go into the spec.<br><div><br></div><div>Of course any wallet can, with B=
IP0075 add support for subscriptions without any spec - just let the user s=
et them up manually.=C2=A0=C2=A0 But it would be nice if a user didn&#39;t =
have to enter the main parameters for subscriptions... too easy to get time=
s amounts, etc wrong.<br></div><div><div><div><br></div></div></div></div><=
div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Jun 22, 20=
16 at 4:11 PM, James MacWhyte <span dir=3D"ltr">&lt;<a href=3D"mailto:macwh=
yte@gmail.com" target=3D"_blank">macwhyte@gmail.com</a>&gt;</span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Thomas,<div><br></div><di=
v>I like your idea about expanding Bitcoin URI&#39;s to include signatures.=
 For BIP75 store and forward servers we are already thinking the DNS record=
 would have the user&#39;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 j=
ust for the public key part. Expanding the Bitcoin URI should be done as we=
ll, for people who want to go the simpler route and not rely on servers.</d=
iv><div><br></div><div>Erik, Andy, everyone else,</div><div><br></div><div>=
I don&#39;t understand why subscriptions would need to be built into the pr=
otocol. With BIP75 the merchant could automatically issue a PaymentRequest =
message every X amount of time, and the customer&#39;s wallet would either =
display the request like normal or be set to pre-authorize requests from th=
e merchant. If the merchant goes out of business, the requests would stop c=
oming. This sounds like a UI issue and not a protocol-level requirement.<br=
><br>If you think I&#39;m wrong, please explain why :)</div><br><div class=
=3D"gmail_quote"><div><div class=3D"h5"><div dir=3D"ltr">On Wed, Jun 22, 20=
16 at 12:35 PM Erik Aronesty via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-=
dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfou=
ndation.org</a>&gt; wrote:<br></div></div></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div><div class=3D"h5"><div dir=3D"ltr"><div><div>- Payment channels se=
em clearly inappropriate for things like monthly subscriptions, the use of =
nlocktime, etc.<br><br></div>- Merchants cannot send requests to users for =
future payments, because users don&#39;t run servers that they can connect =
to.=C2=A0 That&#39;s why BIP0070 works the way it does.<br><br></div><div>-=
 Need to have an interval for subscriptions, at a minimum, and stored in th=
e wallet so next months payment can go out on time<br><br>- Support for var=
ying 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.<br><br></div><div>- The UI you describe is=
 nice - but not unique to the solution.<br></div><div><br><br><br></div></d=
iv><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Jun 22=
, 2016 at 12:20 PM, Andy Schroder <span dir=3D"ltr">&lt;<a href=3D"mailto:i=
nfo@andyschroder.com" target=3D"_blank">info@andyschroder.com</a>&gt;</span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">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&#39;re just paying a family member of friend back for picking som=
ething up for you at the store, and you&#39;ve already payed them many time=
s before).<br>
<br>
For a subscription, wouldn&#39;t it be better to promote payment channels o=
r just send another payment request? I&#39;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&#39;=
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 &quot;b=
ills to pay&quot; tab. Since everything would be automated and consolidated=
 locally, you wouldn&#39;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=
&#39;m wondering if it may be better to just skip over to a completely bett=
er way of doing things.<span><font color=3D"#888888"><br>
<br>
<br>
Andy Schroder</font></span><div><div><br>
<br>
On 06/22/2016 11:30 AM, Erik Aronesty wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
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. <br>
</blockquote>
<br>
<br>
</div></div></blockquote></div><br></div></div></div><span class=3D"">
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</span></blockquote></div></div>
</blockquote></div><br></div>

--001a11407346b3a9100535e3e6e5--