Author: Adam Back 2014-10-09 06:14:31
Published on: 2014-10-09T06:14:31+00:00
The email thread starts with Adam expressing his support for a proposal and mentioning that nlocktime as a script property is inconvenient. Then Alan Reiner responds to the thread, stating that he really likes the proposal and sees plenty of opportunities it can provide. One use case Alan mentions is non-interactive recurring payments with ID-association. He explains how this scheme allows the customer to make N recurring payments to a service. Each transaction uses a CHECKLOCKTIMEVERIFY block number approximately X months in the future. The merchant/service has signing access after the locktime, and the merchant software will continuously watch for and sweep all coins available via this mechanism and credit the appropriate customer account. Alan also notes that both the merchant's address and the user's address are in the script, allowing the service to link payment to the user's account. This feature could make it easy to continue paying for a subscription without explicitly linking each payment to the account. In addition to everything else mentioned by Peter in his original proposal, Alan sees OP_CHECKLOCKTIMEVERIFY as an enabling feature.Wladimir chimes in on the thread, saying that Gavin's change to make nlocktime a function is useful but won't help the existing user base, assuming CHECKLOCKTIMEVERIFY is to go into the next major release. Wladimir believes that the next minor release (0.9.4) could have Gavin's change already. However, he doesn't think CHECKLOCKTIMEVERIFY will make it into the next major release. Once headers-first and pruning is merged, he plans to split off the 0.10 branch and give it time to stabilize with a feature freeze. After that, they plan to do a release before the end of the year. Therefore, Wladimir thinks that the earliest we might see CHECKLOCKTIMEVERIFY is in version 0.11, which would be about six months from then.
Updated on: 2023-06-09T02:50:59.893221+00:00