From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id EDE5BC61 for ; Fri, 14 Apr 2017 20:13:06 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-yb0-f172.google.com (mail-yb0-f172.google.com [209.85.213.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7491B1AE for ; Fri, 14 Apr 2017 20:13:06 +0000 (UTC) Received: by mail-yb0-f172.google.com with SMTP id l201so21019865ybf.0 for ; Fri, 14 Apr 2017 13:13:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rgrant-org.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:from:date:message-id:subject:to; bh=Ikny4ZBFU5q+8VY4ZGZ0Z6EjI73CIrfC7S/C7XuM+LA=; b=p74TWPH1K3NFNUia+mTGl8s0IFoX+lLEqtVoCh1HZEtGiG0s8iBCRwMgJNXNLuOAbk /oAcgBojLbVKv8ofOH5mKuoedh5dOfXvB9WJWaBwEWP5xYc+yi5xWEn8cfZK8588tKH0 7YpldoOJ8QttAFVB6iAe7G07vHuw+9UtWNDBTel32SPv6TJuWI0x9Q31ORBgDkGKu0Of zzr+mR9NX+JLuinqe95Ghd4gh2RZtF5Ffeo7Fq7ocmRtGxpAgWYQnFFb8n8sB8ZhpHQU S/GdI7dafuhJLx1yOcqFv/0KHGq2aXn3wpX6vQZqxJ6N6M5PddTAFK97DvQNI+5kpvQt 9Xxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=Ikny4ZBFU5q+8VY4ZGZ0Z6EjI73CIrfC7S/C7XuM+LA=; b=PFomJcNxXFu0+22K54e1EEkYXL7vP3acw6tjIbjwLHL5ZiR44EvC22VB2efxtcO1w9 0H93FBBVPl2TN5+JWcmReycPQMZgHk3fLnwuJO2H0Vx57vp4elSuXB58qwmBEGlAoXLP nO8g3Igsaf47l/UpIyCt9Fr4gwk07bWJ1envyYsOd1Wz1mFr4xt+8YMqLip71vsmwqIx lFSrxru4IuskKs/YTBGRCGodlJarrQ9jWGkwgDgF7X44qFEhyWYnZ9jFsCrFAKnQ1eCA 0fAozvMZqJDaGKnvBlzhxSmR6cw6NKy4v/Rc4y3C49CLKPx44NgcxcEOG+geLTPjX7bN 5u0w== X-Gm-Message-State: AN3rC/69KOFInnc6DdsqaH/fd3Qf6odGLCd5vxWw/aLUjUTBMHd3kCZx Ua/9vfakTkEjAgNhxwPds1R5v4NQIeMWiSc= X-Received: by 10.37.59.199 with SMTP id i190mr7489198yba.126.1492200785298; Fri, 14 Apr 2017 13:13:05 -0700 (PDT) MIME-Version: 1.0 Sender: rgrant@rgrant.org Received: by 10.37.179.22 with HTTP; Fri, 14 Apr 2017 13:12:34 -0700 (PDT) From: Ryan Grant Date: Fri, 14 Apr 2017 15:12:34 -0500 X-Google-Sender-Auth: nCxs8TYgLuYqHwzb9_CPqH8w-N0 Message-ID: To: bitcoin-dev@lists.linuxfoundation.org Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: [bitcoin-dev] extended BIP9 activation of segwit, for legacy nodes X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 20:13:07 -0000 Segwit has proven more contentious to activate than anticipated (although my read has long been that the technical consensus is clear, despite noisy objections). No matter which method is used to eventually activate segwit, or on what timeline, it would be beneficial if validating nodes already capable of supporting segwit could, without further upgrades, eventually participate to their fullest capacity. BIP9 assignments should reserve a backward compatibility bit which all yet-unknown segwit-compatible proposals may utilize. These future proposals must be consensus compatible with BIPs 141, 143, & 147, except that they may use different deployment logic. The motivation is so that any validating node software released after this BIP9 assignment can eventually understand if segwit is activated by alternate means, even when the node is itself a legacy version. This is important because the realities of system administration on the Bitcoin network are that upgrades occur slowly (which is inherent in the security choice of not presenting an auto-upgrade feature). Even though segwit in particular is backwards compatible with old validating nodes, there are still distinct advantages to validating and generating segregated witness transactions. For example, future BIP9-compatible deployment attempts might additionally include a date-dependent UASF fallback. If, either during or after activation, deployment rules also require signaling for segwit using the backwards-compatible bit here proposed, then (after 95% of recent blocks signal for the alternate segwit deployment) more legacy nodes would understand and validate transactions using segregated witnesses. An expiration time of five years seems conservative: // Alternate Deployment 1 of SegWit (BIP141, BIP143, and BIP147) consensus.vDeployments[Consensus::DEPLOYMENT_SEGWIT_ALT1].bit = 2; consensus.vDeployments[Consensus::DEPLOYMENT_SEGWIT_ALT1].nStartTime = 1510704000; // November 15th, 2017. consensus.vDeployments[Consensus::DEPLOYMENT_SEGWIT_ALT1].nTimeout = 1668470400; // November 15th, 2022. Segwit deployment logic would then look like: bool IsWitnessEnabled(const CBlockIndex* pindexPrev, const Consensus::Params& params) { LOCK(cs_main); return (VersionBitsState(pindexPrev, params, Consensus::DEPLOYMENT_SEGWIT, versionbitscache) == THRESHOLD_ACTIVE) || (VersionBitsState(pindexPrev, params, Consensus::DEPLOYMENT_SEGWIT_ALT1, versionbitscache) == THRESHOLD_ACTIVE); }