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
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <etotheipi@gmail.com>) id 1Xc4AJ-0002Um-Q5
for bitcoin-development@lists.sourceforge.net;
Thu, 09 Oct 2014 03:13:19 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.218.49 as permitted sender)
client-ip=209.85.218.49; envelope-from=etotheipi@gmail.com;
helo=mail-oi0-f49.google.com;
Received: from mail-oi0-f49.google.com ([209.85.218.49])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Xc4AH-000505-S6
for bitcoin-development@lists.sourceforge.net;
Thu, 09 Oct 2014 03:13:19 +0000
Received: by mail-oi0-f49.google.com with SMTP id a3so848935oib.8
for <bitcoin-development@lists.sourceforge.net>;
Wed, 08 Oct 2014 20:13:12 -0700 (PDT)
X-Received: by 10.182.213.131 with SMTP id ns3mr18116083obc.33.1412824392340;
Wed, 08 Oct 2014 20:13:12 -0700 (PDT)
Received: from [10.9.0.10] ([111.90.140.185])
by mx.google.com with ESMTPSA id ls8sm1895389obb.13.2014.10.08.20.13.09
for <bitcoin-development@lists.sourceforge.net>
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Wed, 08 Oct 2014 20:13:11 -0700 (PDT)
Message-ID: <5435FD3D.40409@gmail.com>
Date: Wed, 08 Oct 2014 23:13:01 -0400
From: Alan Reiner <etotheipi@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <20141001130826.GM28710@savin.petertodd.org> <CABbpET8_FMCcnh0dELnHsYmF+YP05Gz=nZ3SPkLZuqXYV3JUpQ@mail.gmail.com> <1987325.zKPNeYyO8K@crushinator> <201410031750.27323.luke@dashjr.org> <CANEZrP1eGi-AHgciQiKUuUB7WwqKsMOyTjCQAAO=RWEkPC2Uiw@mail.gmail.com> <CAJHLa0NRNEQLqA2E=ysXsKw6hWS-H9X_AFYK4ckC4-_Bk=qbSA@mail.gmail.com> <20141004003850.GA23202@muck> <CANEZrP0_jDouDCLn9BvxUd7UYiZLbVsaGGkkxwjcOYxZryBDPQ@mail.gmail.com> <CABsx9T0Q8g9KYRbAvCV=35x5Rb5HFnrNkrwwMZ=Mv-namMEPpg@mail.gmail.com> <CANEZrP2Xp7ene+KDw_L_YnNW=hDt9K-UigvZ6PLb3oUviOr_Tw@mail.gmail.com>
<CA+s+GJC2v+g-SWvqdaD2Fb7bb4DkWTtp+e4QNRGvCo1QtraFnQ@mail.gmail.com>
In-Reply-To: <CA+s+GJC2v+g-SWvqdaD2Fb7bb4DkWTtp+e4QNRGvCo1QtraFnQ@mail.gmail.com>
Content-Type: multipart/alternative;
boundary="------------060305000600090900020606"
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(etotheipi[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Xc4AH-000505-S6
Subject: Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent
a txout from being spent until an expiration time
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 09 Oct 2014 03:13:19 -0000
This is a multi-part message in MIME format.
--------------060305000600090900020606
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
By the way, I really like this proposal. I haven't spent much time
thinking about the deeper subtleties and risks associated with it, but I
see a lot of opportunities. One just came to mind that I didn't see
mentioned in his original proposal:
_Non-Interactive Recurring payments__with ID-association_:
You want to make N recurring payments of 1 BTC each month to a service.=20
Sign N transactions each of them use a CHECKLOCKTIMEVERIFY block number
approximately X months in the future (one for each month). The script
allows the customer to move the coins at any time, but after the
locktime the merchant/service has signing access. The merchant software
will continually watch for and sweep all coins that become available via
this mechanism and credit the appropriate customer account. The
customer maintains control of the funds until payment time, the merchant
can automatically collect it each month without requiring user
interaction, and the customer can cancel it just by spending it
elsewhere before the locktime.=20
This scheme has an added benefit: both the merchant's address and the
user's address is in the script. Given an appropriate scheme for
linking addresses to accounts (perhaps sending the service a watch-only
BIP32 branch), the service can use the other address in the script to
recognize and link that payment to the user's account. This allows you
to continue paying and extending your subscription without having to
explicitly link each payment to the account. The wallet will simply
make sure to use a return address that is in a BIP32 branch that was
provided to the service during signup, and the service will
automatically extend your subscription every month based on that info
when it sweeps payments.
Along with everything else that was mentioned by Peter in his original
proposal, I see OP_CHECKLOCKTIMEVERIFY as an enabling feature, not just
a simple improvement.
=20
-Alan
On 10/08/2014 06:26 AM, Wladimir wrote:
> On Tue, Oct 7, 2014 at 6:08 PM, Mike Hearn <mike@plan99.net> wrote:
>>> That is easy to change; I'll submit a pull request.
>>
>> That's certainly a useful improvement. It won't help the existing user=
base
>> though - assuming CHECKLOCKTIMEVERIFY is to go in to the next major re=
lease.
> The next minor release (0.9.4) could have Gavin's change already.
>
> I don't think CHECKLOCKTIMEVERIFY will make it into the next major
> release though. Once headers-first and pruning is merged (which is
> expected to be a matter of weeks). I'd like to split off the 0.10
> branch and give it some time to stabilize with a feature freeze, then
> do a release before the end of the year.
>
> So 0.11, in say 6 months, would be soonest.
>
> Wladimir
>
> -----------------------------------------------------------------------=
-------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Report=
s
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://pubads.g.doubleclick.net/gampad/clk?id=3D154622311&iu=3D/4140/os=
tg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--------------060305000600090900020606
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
By the way, I really like this proposal. I haven't spent much time
thinking about the deeper subtleties and risks associated with it,
but I see a lot of opportunities. One just came to mind that I
didn't see mentioned in his original proposal:<br>
<br>
<u>Non-Interactive Recurring payments</u><u> with ID-association</u>:<br>
You want to make N recurring payments of 1 BTC each month to a
service. Sign N transactions each of them use a CHECKLOCKTIMEVERIFY
block number approximately X months in the future (one for each
month). The script allows the customer to move the coins at any
time, but after the locktime the merchant/service has signing
access. The merchant software will continually watch for and sweep
all coins that become available via this mechanism and credit the
appropriate customer account. The customer maintains control of the
funds until payment time, the merchant can automatically collect it
each month without requiring user interaction, and the customer can
cancel it just by spending it elsewhere before the locktime. <br>
<br>
This scheme has an added benefit: both the merchant's address and
the user's address is in the script. Given an appropriate scheme
for linking addresses to accounts (perhaps sending the service a
watch-only BIP32 branch), the service can use the other address in
the script to recognize and link that payment to the user's
account. This allows you to continue paying and extending your
subscription without having to explicitly link each payment to the
account. The wallet will simply make sure to use a return address
that is in a BIP32 branch that was provided to the service during
signup, and the service will automatically extend your subscription
every month based on that info when it sweeps payments.<br>
<br>
Along with everything else that was mentioned by Peter in his
original proposal, I see OP_CHECKLOCKTIMEVERIFY as an enabling
feature, not just a simple improvement.<br>
<br>
-Alan<br>
<br>
<br>
<div class="moz-cite-prefix">On 10/08/2014 06:26 AM, Wladimir wrote:<br>
</div>
<blockquote
cite="mid:CA+s+GJC2v+g-SWvqdaD2Fb7bb4DkWTtp+e4QNRGvCo1QtraFnQ@mail.gmail.com"
type="cite">
<pre wrap="">On Tue, Oct 7, 2014 at 6:08 PM, Mike Hearn <a class="moz-txt-link-rfc2396E" href="mailto:mike@plan99.net"><mike@plan99.net></a> wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">That is easy to change; I'll submit a pull request.
</pre>
</blockquote>
<pre wrap="">
That's certainly a useful improvement. It won't help the existing userbase
though - assuming CHECKLOCKTIMEVERIFY is to go in to the next major release.
</pre>
</blockquote>
<pre wrap="">
The next minor release (0.9.4) could have Gavin's change already.
I don't think CHECKLOCKTIMEVERIFY will make it into the next major
release though. Once headers-first and pruning is merged (which is
expected to be a matter of weeks). I'd like to split off the 0.10
branch and give it some time to stabilize with a feature freeze, then
do a release before the end of the year.
So 0.11, in say 6 months, would be soonest.
Wladimir
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
<a class="moz-txt-link-freetext" href="http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk">http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk</a>
_______________________________________________
Bitcoin-development mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a>
</pre>
</blockquote>
<br>
</body>
</html>
--------------060305000600090900020606--
|
