From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Xc6zm-0002dR-SB for bitcoin-development@lists.sourceforge.net; Thu, 09 Oct 2014 06:14:40 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.192.50 as permitted sender) client-ip=209.85.192.50; envelope-from=adam.back@gmail.com; helo=mail-qg0-f50.google.com; Received: from mail-qg0-f50.google.com ([209.85.192.50]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Xc6zl-0001s9-Ht for bitcoin-development@lists.sourceforge.net; Thu, 09 Oct 2014 06:14:38 +0000 Received: by mail-qg0-f50.google.com with SMTP id q108so666450qgd.9 for ; Wed, 08 Oct 2014 23:14:32 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.224.66.7 with SMTP id l7mr20386989qai.71.1412835271976; Wed, 08 Oct 2014 23:14:31 -0700 (PDT) Sender: adam.back@gmail.com Received: by 10.96.238.71 with HTTP; Wed, 8 Oct 2014 23:14:31 -0700 (PDT) In-Reply-To: <5435FD3D.40409@gmail.com> References: <20141001130826.GM28710@savin.petertodd.org> <1987325.zKPNeYyO8K@crushinator> <201410031750.27323.luke@dashjr.org> <20141004003850.GA23202@muck> <5435FD3D.40409@gmail.com> Date: Thu, 9 Oct 2014 07:14:31 +0100 X-Google-Sender-Auth: FX_SdE5EepgS5rYVGAn3JN2sxOQ Message-ID: From: Adam Back To: Alan Reiner Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.5 (-) 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 (adam.back[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 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: 1Xc6zl-0001s9-Ht Cc: Bitcoin Dev 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 06:14:40 -0000 I think you can do everything with the existing script level nlocktime in some kind of turing completeness sense (maybe); but there is a complexity cost that often you have to resort to extra dependent transaction(s) (and work-around malleability until that is fully fixed) just to get the effect. When I tried building things that need nlocktime I found it quite inconvenient that it was wasnt a function rather than a script property, so I like this proposal. Adam On 9 October 2014 04:13, Alan Reiner wrote: > 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 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 > > > > ------------------------------------------------------------------------------ > 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 >