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