Published on: 2015-07-18T19:48:32+00:00
The Block validity section of BIP62, which references version 3 blocks already used by the BIP66 soft fork, is currently a low priority in the soft-fork logjam. However, this issue will be fixed. There is no deployment timeline for BIP62 at present. The uncontroversial aspects of BIP62 were quickly released as BIP66 after an undisclosed vulnerability was discovered. BIP65: CHECKLOCKTIMEVERIFY has higher deployment priority than BIP62, and there is consensus on that. Multiple soft forks can be upgraded signaling at a time, but it is not considered a vote because if miners do not upgrade, there is no easy way to recover. Peter Todd co-authored nVersion bits, a mechanism closer to a vote, as failed soft forks have a clear and non-coercive outcome. If BIP65 was accepted into v0.11.0, miners running v0.10.x/0.9.5 would have signaled support for BIP66, while miners using v0.11.0 would signal support for both BIP66 and BIP65. However, there would be no mechanism to implement BIP65 if miners disliked BIP66 but wanted to implement BIP65, possibly leading to a hard-fork in Bitcoin.In an email thread, Mark Friedenbach explains that due to a soft-fork logjam, there is no deployment timeline for BIP62. The Bitcoin development team can push out more than one soft-fork upgrade signaling at a time, but it is not considered a vote because if miners decide not to upgrade, there is no easy way to recover. Friedenbach co-authored the nVersion bits mechanism, which is closer to a vote as failed soft-forks have a clear and non-coercive outcome. If BIP65 had been accepted into v0.11.0, miners running v0.10.x/0.9.5 would have signaled support for BIP66, while miners using v0.11.0 would signal support for both BIP66 and BIP65. However, if miners disliked BIP66 but wanted to implement BIP65, there would be no mechanism to do so, potentially resulting in a hard-fork.In an email conversation between Nick ODell and a Bitcoin developer, concerns were raised regarding the deployment timeline for BIP62. The developer explained that currently only one soft fork vote can be pushed out at a time. BIP66 was rushed out in response to an undisclosed vulnerability, incorporating the uncontroversial aspects of BIP62. However, BIP65: CHECKLOCKTIMEVERIFY has higher deployment priority and will be next. As BIP62 is considered low priority, there is no specific deployment timeline. The developer also sought specifics on why BIP62 is considered outdated, as any identified issues would be addressed.The Bitcoin Improvement Proposal (BIP) 62 is not abandoned but requires time for implementation and ensuring safety. BIP66 includes some features from BIP62, while rules 2-7 have been nonstandard for some time and are not enforced against new blocks. On July 18, 2015, Nick ODell expressed uncertainty about the status of BIP62, noting that the PR based on it was never merged. Rusty Russell posted a draft of Lightning Network Deployment guidelines on July 17, 2015, seeking feedback from the Lightning-dev mailing list. Despite lacking proofreading, he shared it for review before the weekend.BIP62 is believed to be abandoned as the PR based on it was never merged. However, BIP66 incorporates some of its rules, while rules 2-7 have been nonstandard and not enforced against new blocks. Rusty Russell posted a draft regarding ln-deploy which has not been proofread properly yet, and script examples have not been checked. The post was made on the Lightning-dev mailing list.On July 17, 2015, Rusty Russell proposed a construction to deploy lightning on Bitcoin, including the use of OP_CHECKLOCKTIMEVERIFY and OP_CHECKSEQUENCEVERIFY for quicker deployment. Joseph Poon expressed excitement about the proposal, mentioning its significance in creating a usable way to try out lightning on Bitcoin. Poon planned to update his paper with these changes. Rusty's draft can be found at http://lightning.network/lightning-network-paper-0.5.9.pdf.Rusty Russell, a well-known Linux kernel developer, shared a draft of his ln-deploy project. He posted the document on ozlabs.org for feedback, offering an overview of deploying Lightning Network (LN) nodes using his ln-node software. The draft, titled "ln-deploy-draft-01.pdf," is still a work in progress and lacks proofreading and checked script examples. However, Rusty wanted others to review it before the weekend.
Updated on: 2023-07-31T18:08:57.523958+00:00