1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
|
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 3CA3C92
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 22 Jun 2016 17:07:23 +0000 (UTC)
Received: by mail-yw0-f171.google.com with SMTP id l125so47849078ywb.2
for <bitcoin-dev@lists.linuxfoundation.org>;
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: <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>
From: Erik Aronesty <erik@q32.com>
Date: Wed, 22 Jun 2016 13:07:21 -0400
X-Google-Sender-Auth: YK0P_a5J1Q4vnPCJ-gI_7XLdpQI
Message-ID: <CAJowKgJMn5BDUUyQAU56XV-spUmy3GWHAieVEA9Nm9Y6ct7TNw@mail.gmail.com>
To: Andy Schroder <info@andyschroder.com>
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 <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 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 <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.
>>
>
>
>
--001a11c05a548c569e0535e0f889
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div>- Payment channels seem clearly inappropriate fo=
r things like monthly subscriptions, the use of nlocktime, etc.<br><br></di=
v>- 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.<br><br></div><div>- 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<br><br>- 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.<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"><<a href=3D"mailto:i=
nfo@andyschroder.com" target=3D"_blank">info@andyschroder.com</a>></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'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).<br>
<br>
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.<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
<br>
Andy Schroder</font></span><div class=3D"HOEnZb"><div class=3D"h5"><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>
--001a11c05a548c569e0535e0f889--
|
