From: Alan Reiner <etotheipi@gmail•com>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time
Date: Wed, 08 Oct 2014 23:13:01 -0400 [thread overview]
Message-ID: <5435FD3D.40409@gmail.com> (raw)
In-Reply-To: <CA+s+GJC2v+g-SWvqdaD2Fb7bb4DkWTtp+e4QNRGvCo1QtraFnQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3408 bytes --]
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.
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.
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.
-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 userbase
>> though - assuming CHECKLOCKTIMEVERIFY is to go in to the next major release.
> 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
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[-- Attachment #2: Type: text/html, Size: 4480 bytes --]
next prev parent reply other threads:[~2014-10-09 3:13 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-01 13:08 Peter Todd
2014-10-01 15:01 ` Gavin Andresen
2014-10-02 1:06 ` Peter Todd
2014-10-01 15:29 ` Sergio Lerner
2014-10-01 17:06 ` Peter Todd
2014-10-01 18:23 ` Luke Dashjr
2014-10-01 20:58 ` Gavin Andresen
2014-10-01 21:04 ` Alan Reiner
2014-10-01 21:34 ` Gavin Andresen
2014-10-02 0:12 ` Peter Todd
2014-10-02 0:05 ` Peter Todd
2014-10-02 0:55 ` Luke Dashjr
2014-10-02 1:09 ` Peter Todd
2014-10-02 15:05 ` Flavien Charlon
2014-10-03 14:28 ` Matt Whitlock
2014-10-03 14:30 ` Matt Whitlock
2014-10-03 16:17 ` Gregory Maxwell
2014-10-03 17:50 ` Luke Dashjr
2014-10-03 20:58 ` Mike Hearn
2014-10-03 23:12 ` Jeff Garzik
2014-10-04 0:38 ` Peter Todd
2014-10-04 12:58 ` Mike Hearn
2014-10-07 15:50 ` Gavin Andresen
2014-10-07 16:08 ` Mike Hearn
2014-10-08 10:26 ` Wladimir
2014-10-09 3:13 ` Alan Reiner [this message]
2014-10-09 6:14 ` Adam Back
2014-10-09 6:28 ` Gregory Maxwell
2014-10-09 6:33 ` Peter Todd
2014-10-09 6:40 ` Gregory Maxwell
2014-10-08 4:07 ` Tom Harding
2014-10-08 10:15 ` Mike Hearn
2015-03-16 22:22 ` [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal) Matt Corallo
2015-03-19 17:39 ` Zooko Wilcox-OHearn
2015-04-21 7:59 ` Peter Todd
2015-04-26 11:35 ` Jorge Timón
2015-04-26 12:20 ` Jorge Timón
2015-04-27 19:35 ` Peter Todd
2015-04-28 7:44 ` Jorge Timón
2015-05-04 2:15 ` Matt Corallo
2015-05-04 11:24 ` Jorge Timón
2015-05-05 0:41 ` Btc Drak
2015-05-05 19:19 ` Jorge Timón
2015-05-05 20:38 ` Tier Nolan
2015-05-06 7:37 ` Jorge Timón
2015-05-06 22:09 ` Tier Nolan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5435FD3D.40409@gmail.com \
--to=etotheipi@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox