{"type":"rich","version":"1.0","author_name":"npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0u","author_url":"https://nostr.ae/npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0u","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-09-27\n📝 Original message:Agree with all CLTV and nVersionBits points. We should deploy a lock-time\nsoft-fork ASAP, using the tried and true IsSuperMajoirty test.\n\nHowever your information regarding BIPs 68 (sequence numbers), 112\n(checksequenceverify) and 113 (median time past) is outdated. Debate\nregarding semantics has been settled, and there are working implementations\nready for merge on github. See pull requests #6312, #6564, and #6566. I\ndon’t know what the hold up has been regarding further reviews and merging,\nbut it is ready.\n\nIf you believe there are reasons #6312, #6564, or #6566 should not be\nmerged, please speak up. Otherwise it appears there is consensus on these\nchanges. They are related, and there is no reason not to include them in\nthe soft-fork, delaying applications using these features by 6-12 months.\n\nOn Sun, Sep 27, 2015 at 11:50 AM, Peter Todd via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Summary\n\u003e -------\n\u003e\n\u003e It's time to deploy BIP65 CHECKLOCKTIMEVERIFY.\n\u003e\n\u003e I've backported the CLTV op-code and a IsSuperMajority() soft-fork to\n\u003e the v0.10 and v0.11 branches, pull-reqs #6706 and #6707 respectively. A\n\u003e pull-req for git HEAD for the soft-fork deployment has been open since\n\u003e June 28th, #6351 - the opcode implementation itself was merged two\n\u003e months ago.\n\u003e\n\u003e We should release a v0.10.3 and v0.11.1 with CLTV and get the ball\n\u003e rolling on miner adoption. We have consensus that we need CLTV, we have\n\u003e a well tested implementation, and we have a well-tested deployment\n\u003e mechanism. We also don't need to wait for other soft-fork proposals to\n\u003e catch up - starting the CLTV deployment process isn't going to delay\n\u003e future soft-forks, or for that matter, hard-forks.\n\u003e\n\u003e I think it's possible to safely get CLTV live on mainnet before the end\n\u003e of the year. It's time we get this over with and done.\n\u003e\n\u003e\n\u003e Detailed Rational\n\u003e -----------------\n\u003e\n\u003e 1) There is a clear need for CLTV\n\u003e\n\u003e Escrow and payment channels both benefit greatly from CLTV. In\n\u003e particular, payment channel implementations are made significantly\n\u003e simpler with CLTV, as well as more secure by removing the malleability\n\u003e vulnerability.\n\u003e\n\u003e Why are payment channels important? There's a lot of BTC out there\n\u003e vulnerable to theft that doesn't have to be. For example, just the other\n\u003e day I was talking with Nick Sullivan about ChangeTip's vulnerability to\n\u003e theft, as well as regulatory uncertainty about whether or not they're a\n\u003e custodian of their users' funds. With payment channels ChangeTip would\n\u003e only be able to spend as much of a deposit as a user had spent, keeping\n\u003e the rest safe from theft. Similarly, in the other direction - ChangeTip\n\u003e to their users - in many cases it is feasible to also use payment\n\u003e channels to immediately give users control of their funds as they\n\u003e receive them, again protecting users and helping make the case that\n\u003e they're not a custodian. In the future I'm sure we'll see fancy\n\u003e bi-directional payment channels serving this role, but lets not let\n\u003e perfect be the enemy of good.\n\u003e\n\u003e\n\u003e 2) We have consensus on the semantics of the CLTV opcode\n\u003e\n\u003e Pull-req #6124 - the implementation of the opcode itself - was merged\n\u003e nearly three months ago after significant peer review and discussion.\n\u003e Part of that review process included myself(1) and mruddy(2) writing\n\u003e actual demos of CLTV. The chance of the CLTV semantics changing now is\n\u003e near-zero.\n\u003e\n\u003e\n\u003e 3) We have consensus that Bitcoin should adopt CLTV\n\u003e\n\u003e The broad peer review and discussion that got #6124 merged is a clear\n\u003e sign that we expect CLTV to be eventually adopted. The question isn't if\n\u003e CLTV should be added to the Bitcoin protocol, but rather when.\n\u003e\n\u003e\n\u003e 4) The CLTV opcode and IsSuperMajority() deployment code has been\n\u003e    thoroughly tested and reviewed\n\u003e\n\u003e The opcode implementation is very simple, yet got significant review,\n\u003e and it has solid test coverage by a suite of tx-(in)valid.json tests.\n\u003e The tests themselves have been reviewed by others, resulting in Esteban\n\u003e Ordano's pull-req #6368 by Esteban Ordano which added a few more cases.\n\u003e\n\u003e As for the deployment code, both the actual IsSuperMajority() deployment\n\u003e code and associated unit-tests tests were copied nearly line-by-line\n\u003e from the succesful BIP66. I did this deliberately to make all the peer\n\u003e review and testing of the deployment mechanism used in BIP66 be equally\n\u003e valid for CLTV.\n\u003e\n\u003e\n\u003e 5) We can safely deploy CLTV with IsSuperMajority()\n\u003e\n\u003e We've done two soft-forks so far with the IsSuperMajority() mechanism,\n\u003e BIP34 and BIP66. In both cases the IsSuperMajority() mechanism itself\n\u003e worked flawlessly. As is well-known BIP66 in combination with a large %\n\u003e of the hashing power running non-validating \"SPV\" mining operations did\n\u003e lead to a temporary fork, however the root cause of this issue is\n\u003e unavoidable and not unique to IsSuperMajority() soft-forks.\n\u003e\n\u003e Pragmatically speaking, now that miners are well aware of the issue it\n\u003e will be easy for them to avoid a repeat of that fork by simply adding\n\u003e IsSuperMajority() rules to their \"SPV\" mining code. Equally turning off\n\u003e SPV mining (temporarily) is perfectly feasable.\n\u003e\n\u003e\n\u003e 6) We have the necessary consensus to deploy CLTV via IsSuperMajority()\n\u003e\n\u003e The various \"nVersion bits\" proposals - which I am a co-author of - have\n\u003e the primary advantage of being able to cleanly deal with the case where\n\u003e a soft-fork fails to get adopted. However, we do have broad consensus,\n\u003e including across all sides of the blocksize debate, that CLTV should be\n\u003e adopted. The risk of CLTV failing to get miner adoption, and thus\n\u003e blocking other soft-forks, is very low.\n\u003e\n\u003e\n\u003e 7) Using IsSuperMajority() to deploy CLTV doesn't limit or delay other\n\u003e upgrades\n\u003e\n\u003e It _is_ possible for multiple IsSuperMajority() soft-forks to coexist,\n\u003e in the sense that if one soft-fork is \"in flight\" that doesn't prevent\n\u003e another soft-fork from also being deployed simultaneously.\n\u003e\n\u003e In particular, if we deploy CLTV via IsSuperMajority() that does _not_\n\u003e impact the adoption schedule for other future soft-forks, including\n\u003e soft-forks using a future nVersion bits deployment mechanism.\n\u003e\n\u003e For instance, suppose we start deployment of CLTV right now with\n\u003e nVersion=4 blocks. In three months we have 25% miner support, and start\n\u003e deploying CHECKSEQUENCEVERIFY with nVersion=5 blocks. For miners\n\u003e supporting only OP_CLTV, the nVersion=5 blocks still trigger OP_CLTV;\n\u003e miners creating nVersion=5 blocks are simply stating that they support\n\u003e both soft-forks. Equally, if in three months we finish a nVersion bits\n\u003e proposal, those miners will be advertising nVersion=(1 \u003c\u003c 29) blocks,\n\u003e which also advertise OP_CLTV support.\n\u003e\n\u003e\n\u003e 8) BIP101 miners have not proved to be a problem for CLTV deployment\n\u003e\n\u003e While there was concern that BIP101's use of nVersion would cause\n\u003e issues with a IsSuperMajority() softfork, the % of blocks with BIP101\n\u003e nVersion's never reached more than 1%, and currently is hovering at\n\u003e around 0.1%\n\u003e\n\u003e As Gavin Andresen has stated that he is happy to add CLTV to BIP101, and\n\u003e thus Bitcoin XT, I believe we can expect those miners to safely support\n\u003e CLTV well before soft-fork enforcement happens. Secondly, the 95%\n\u003e enforcement threshold means we can tolerate a fairly high % of miners\n\u003e running pre-CLTV BIP101 implementations without fatal effects in the\n\u003e unlikely event that those miners don't upgrade.\n\u003e\n\u003e\n\u003e 9) Doing another IsSuperMajority() soft-fork doesn't \"burn a bit\"\n\u003e\n\u003e This is a common myth! All nVersion bits proposals involve permanently\n\u003e setting a high-order bit to 1, which results in nVersion \u003e= all prior\n\u003e IsSuperMajority() soft-forks. In short, we can do a nearly unlimited\n\u003e number of IsSuperMajority() soft-forks without affecting future nVersion\n\u003e bits soft-forks at all.\n\u003e\n\u003e\n\u003e 10) Waiting for nVersion bits and CHECKSEQUENCEVERIFY will significantly\n\u003e     delay deployment of CLTV\n\u003e\n\u003e It's been proposed multiple times that we wait until we can do a single\n\u003e soft-fork with CSV using the nVersion bits mechanism.\n\u003e\n\u003e nVersion bits doesn't even have an implementation yet, nor has solid\n\u003e consensus been reached on the exact semantics of how nVersion bits\n\u003e should work. The stateful nature of nVersion bits soft-forks requires a\n\u003e significant amount of new code compared to IsSuperMajority() soft-forks,\n\u003e which in turn will require a significant amount of testing. (again I'll\n\u003e point out I'm a co-author to all the nVersion bits proposals)\n\u003e\n\u003e CSV has an implementation, but there is still debate going on about what\n\u003e the exact semantics of it should be. Getting the semantics right is\n\u003e especially important as part of CSV includes changing the meaning of\n\u003e nSequence, restricting future uses of that field. There have been many\n\u003e proposals to use nSequence, e.g. for proof-of-stake blocksize voting,\n\u003e and it has the unique capability of being a field that is both unused,\n\u003e and signed by scriptSigs. We shouldn't take potentially restricting\n\u003e future uses of it lightly.\n\u003e\n\u003e CSV is also significantly more complex and invasive than CLTV in terms\n\u003e of code changes. A large % of the mining power is running forks\n\u003e of Bitcoin Core with custom changes - modifying these forks with new\n\u003e features is a labor intensive and slow process.\n\u003e\n\u003e If CLTV is ready now, why delay it - potentially for 6-12 months - for\n\u003e other proposals to catch up? Equally if they do catch up, great! As\n\u003e explained above an in-flight CLTV soft-fork won't delay future upgrades.\n\u003e\n\u003e\n\u003e 11) Even if CLTV is broken/obsoleted there is very little carrying cost\n\u003e     to having it\n\u003e\n\u003e Suppose we decide in two years that CLTV was botched and we need to fix\n\u003e it. What's the \"carrying cost\" of having implemented CLTV in the first\n\u003e place?\n\u003e\n\u003e We'll have used up one of our ten soft-forkable NOPs, but if we ever\n\u003e \"run out\" it's easy to use extension NOPs(3). Similarly, future script\n\u003e improvements like OP_MAST - or even a hard-fork - can easily expand the\n\u003e range of NOPs to the point where this is a non-issue.\n\u003e\n\u003e If you don't use OP_CLTV in your scripts there is zero effect on your\n\u003e transactions; we're not limiting future improvements to Bitcoin in any\n\u003e way other than using up a NOP by implementing CLTV.\n\u003e\n\u003e\n\u003e References\n\u003e ----------\n\u003e\n\u003e 1) https://github.com/petertodd/checklocktimeverify-demos\n\u003e 2) https://github.com/mruddy/bip65-demos\n\u003e 3) https://github.com/bitcoin/bitcoin/pull/5496#issuecomment-101293403\n\u003e 4) https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki\n\u003e\n\u003e --\n\u003e 'peter'[:-1]@petertodd.org\n\u003e 000000000000000006a257845da185433cbde54a74be889b1c046a267dcf4ab2\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150927/7fbbbfa6/attachment-0001.html\u003e"}