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 <etothe...@gmail.com> 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 <m...@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 > > > > ------------------------------------------------------------------------------ > 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
