{"type":"rich","version":"1.0","author_name":"npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","author_url":"https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-09-27\n📝 Original message:Summary\n-------\n\nIt's time to deploy BIP65 CHECKLOCKTIMEVERIFY.\n\nI've backported the CLTV op-code and a IsSuperMajority() soft-fork to\nthe v0.10 and v0.11 branches, pull-reqs #6706 and #6707 respectively. A\npull-req for git HEAD for the soft-fork deployment has been open since\nJune 28th, #6351 - the opcode implementation itself was merged two\nmonths ago.\n\nWe should release a v0.10.3 and v0.11.1 with CLTV and get the ball\nrolling on miner adoption. We have consensus that we need CLTV, we have\na well tested implementation, and we have a well-tested deployment\nmechanism. We also don't need to wait for other soft-fork proposals to\ncatch up - starting the CLTV deployment process isn't going to delay\nfuture soft-forks, or for that matter, hard-forks.\n\nI think it's possible to safely get CLTV live on mainnet before the end\nof the year. It's time we get this over with and done.\n\n\nDetailed Rational\n-----------------\n\n1) There is a clear need for CLTV\n\nEscrow and payment channels both benefit greatly from CLTV. In\nparticular, payment channel implementations are made significantly\nsimpler with CLTV, as well as more secure by removing the malleability\nvulnerability.\n\nWhy are payment channels important? There's a lot of BTC out there\nvulnerable to theft that doesn't have to be. For example, just the other\nday I was talking with Nick Sullivan about ChangeTip's vulnerability to\ntheft, as well as regulatory uncertainty about whether or not they're a\ncustodian of their users' funds. With payment channels ChangeTip would\nonly be able to spend as much of a deposit as a user had spent, keeping\nthe rest safe from theft. Similarly, in the other direction - ChangeTip\nto their users - in many cases it is feasible to also use payment\nchannels to immediately give users control of their funds as they\nreceive them, again protecting users and helping make the case that\nthey're not a custodian. In the future I'm sure we'll see fancy\nbi-directional payment channels serving this role, but lets not let\nperfect be the enemy of good.\n\n\n2) We have consensus on the semantics of the CLTV opcode\n\nPull-req #6124 - the implementation of the opcode itself - was merged\nnearly three months ago after significant peer review and discussion.\nPart of that review process included myself(1) and mruddy(2) writing\nactual demos of CLTV. The chance of the CLTV semantics changing now is\nnear-zero.\n\n\n3) We have consensus that Bitcoin should adopt CLTV\n\nThe broad peer review and discussion that got #6124 merged is a clear\nsign that we expect CLTV to be eventually adopted. The question isn't if\nCLTV should be added to the Bitcoin protocol, but rather when.\n\n\n4) The CLTV opcode and IsSuperMajority() deployment code has been\n   thoroughly tested and reviewed\n\nThe opcode implementation is very simple, yet got significant review,\nand it has solid test coverage by a suite of tx-(in)valid.json tests.\nThe tests themselves have been reviewed by others, resulting in Esteban\nOrdano's pull-req #6368 by Esteban Ordano which added a few more cases.\n\nAs for the deployment code, both the actual IsSuperMajority() deployment\ncode and associated unit-tests tests were copied nearly line-by-line\nfrom the succesful BIP66. I did this deliberately to make all the peer\nreview and testing of the deployment mechanism used in BIP66 be equally\nvalid for CLTV.\n\n\n5) We can safely deploy CLTV with IsSuperMajority()\n\nWe've done two soft-forks so far with the IsSuperMajority() mechanism,\nBIP34 and BIP66. In both cases the IsSuperMajority() mechanism itself\nworked flawlessly. As is well-known BIP66 in combination with a large %\nof the hashing power running non-validating \"SPV\" mining operations did\nlead to a temporary fork, however the root cause of this issue is\nunavoidable and not unique to IsSuperMajority() soft-forks.\n\nPragmatically speaking, now that miners are well aware of the issue it\nwill be easy for them to avoid a repeat of that fork by simply adding\nIsSuperMajority() rules to their \"SPV\" mining code. Equally turning off\nSPV mining (temporarily) is perfectly feasable.\n\n\n6) We have the necessary consensus to deploy CLTV via IsSuperMajority()\n\nThe various \"nVersion bits\" proposals - which I am a co-author of - have\nthe primary advantage of being able to cleanly deal with the case where\na soft-fork fails to get adopted. However, we do have broad consensus,\nincluding across all sides of the blocksize debate, that CLTV should be\nadopted. The risk of CLTV failing to get miner adoption, and thus\nblocking other soft-forks, is very low.\n\n\n7) Using IsSuperMajority() to deploy CLTV doesn't limit or delay other upgrades\n\nIt _is_ possible for multiple IsSuperMajority() soft-forks to coexist,\nin the sense that if one soft-fork is \"in flight\" that doesn't prevent\nanother soft-fork from also being deployed simultaneously.\n\nIn particular, if we deploy CLTV via IsSuperMajority() that does _not_\nimpact the adoption schedule for other future soft-forks, including\nsoft-forks using a future nVersion bits deployment mechanism.\n\nFor instance, suppose we start deployment of CLTV right now with\nnVersion=4 blocks. In three months we have 25% miner support, and start\ndeploying CHECKSEQUENCEVERIFY with nVersion=5 blocks. For miners\nsupporting only OP_CLTV, the nVersion=5 blocks still trigger OP_CLTV;\nminers creating nVersion=5 blocks are simply stating that they support\nboth soft-forks. Equally, if in three months we finish a nVersion bits\nproposal, those miners will be advertising nVersion=(1 \u003c\u003c 29) blocks,\nwhich also advertise OP_CLTV support.\n\n\n8) BIP101 miners have not proved to be a problem for CLTV deployment\n\nWhile there was concern that BIP101's use of nVersion would cause\nissues with a IsSuperMajority() softfork, the % of blocks with BIP101\nnVersion's never reached more than 1%, and currently is hovering at\naround 0.1%\n\nAs Gavin Andresen has stated that he is happy to add CLTV to BIP101, and\nthus Bitcoin XT, I believe we can expect those miners to safely support\nCLTV well before soft-fork enforcement happens. Secondly, the 95%\nenforcement threshold means we can tolerate a fairly high % of miners\nrunning pre-CLTV BIP101 implementations without fatal effects in the\nunlikely event that those miners don't upgrade.\n\n\n9) Doing another IsSuperMajority() soft-fork doesn't \"burn a bit\"\n\nThis is a common myth! All nVersion bits proposals involve permanently\nsetting a high-order bit to 1, which results in nVersion \u003e= all prior\nIsSuperMajority() soft-forks. In short, we can do a nearly unlimited\nnumber of IsSuperMajority() soft-forks without affecting future nVersion\nbits soft-forks at all.\n\n\n10) Waiting for nVersion bits and CHECKSEQUENCEVERIFY will significantly\n    delay deployment of CLTV\n\nIt's been proposed multiple times that we wait until we can do a single\nsoft-fork with CSV using the nVersion bits mechanism.\n\nnVersion bits doesn't even have an implementation yet, nor has solid\nconsensus been reached on the exact semantics of how nVersion bits\nshould work. The stateful nature of nVersion bits soft-forks requires a\nsignificant amount of new code compared to IsSuperMajority() soft-forks,\nwhich in turn will require a significant amount of testing. (again I'll\npoint out I'm a co-author to all the nVersion bits proposals)\n\nCSV has an implementation, but there is still debate going on about what\nthe exact semantics of it should be. Getting the semantics right is\nespecially important as part of CSV includes changing the meaning of\nnSequence, restricting future uses of that field. There have been many\nproposals to use nSequence, e.g. for proof-of-stake blocksize voting,\nand it has the unique capability of being a field that is both unused,\nand signed by scriptSigs. We shouldn't take potentially restricting\nfuture uses of it lightly.\n\nCSV is also significantly more complex and invasive than CLTV in terms\nof code changes. A large % of the mining power is running forks\nof Bitcoin Core with custom changes - modifying these forks with new\nfeatures is a labor intensive and slow process.\n\nIf CLTV is ready now, why delay it - potentially for 6-12 months - for\nother proposals to catch up? Equally if they do catch up, great! As\nexplained above an in-flight CLTV soft-fork won't delay future upgrades.\n\n\n11) Even if CLTV is broken/obsoleted there is very little carrying cost\n    to having it\n\nSuppose we decide in two years that CLTV was botched and we need to fix\nit. What's the \"carrying cost\" of having implemented CLTV in the first\nplace?\n\nWe'll have used up one of our ten soft-forkable NOPs, but if we ever\n\"run out\" it's easy to use extension NOPs(3). Similarly, future script\nimprovements like OP_MAST - or even a hard-fork - can easily expand the\nrange of NOPs to the point where this is a non-issue.\n\nIf you don't use OP_CLTV in your scripts there is zero effect on your\ntransactions; we're not limiting future improvements to Bitcoin in any\nway other than using up a NOP by implementing CLTV.\n\n\nReferences\n----------\n\n1) https://github.com/petertodd/checklocktimeverify-demos\n2) https://github.com/mruddy/bip65-demos\n3) https://github.com/bitcoin/bitcoin/pull/5496#issuecomment-101293403\n4) https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki\n\n-- \n'peter'[:-1]@petertodd.org\n000000000000000006a257845da185433cbde54a74be889b1c046a267dcf4ab2\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 650 bytes\nDesc: Digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150927/3c7f726e/attachment.sig\u003e"}