Author: s7r 2015-10-04 12:04:16
Published on: 2015-10-04T12:04:16+00:00
The email conversation is between Anthony Towns and Peter Todd via bitcoin-dev. They discuss the implementation of relative CLTV using nSequence in Bitcoin transactions. Todd proposes that two things need to be made clear: 1) there are applications that require relative instead of absolute CLTV and 2) the implementation should be done through nSequence. Towns asks for a simple Alice and Bob example, and Todd explains that RCLTV/OP_CSV is used in Lightning commitment transactions to enforce a delay between publishing the commitment transaction and spending the output. Using absolute CLTV would mean that once the effective delay a commitment transaction has decreases over time, but over time it will become too short, which means there is not enough time to prove cheating, and the channel has to be closed prematurely. Todd explains that there is a small drawback in that the initial transaction could be delayed, reducing the overall time the channel exists. Towns agrees that CLTV/RCLTV is necessary in day-to-day use cases, and they discuss the use cases for BIP68 (nSequence). Todd concludes that OP_CRLTV alone works fine, and BIP112 is required for the rest.
Updated on: 2023-06-10T23:47:22.373942+00:00