Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 65E4211DF for ; Wed, 28 Mar 2018 12:55:28 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f49.google.com (mail-vk0-f49.google.com [209.85.213.49]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CACF5613 for ; Wed, 28 Mar 2018 12:55:27 +0000 (UTC) Received: by mail-vk0-f49.google.com with SMTP id q198so1309583vke.3 for ; Wed, 28 Mar 2018 05:55:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jtimon-cc.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=eovIoKsLh+X8F80ZqvoQ/K6quxM5fHADO6wFiNQ33Ns=; b=LQH3mNk5M1maxNhEgxrPyEcXu411HXJrD267A4tPmovzuWIo6gxeZAr1sDIBfnXZ5I owOdpNUFwlEEm+7ouaGIHDr0JNWpes+5RvwIhIaaiGXaBDp6w8w+BNafwrDEPqqxdq0D ykGwN5cyxWYPCEV+RgM/+F2epDYqhibxKXMMHhgvX/ggujzYyzojW3NUU902CceKs8zv KJ2TPPqAH4w4+JAoVWEPyHMGSEk3MQIfWHXzgIAx4lDAPKqsZ+2t5RUPc7ezwkS0mLuP bSCAzOWeMCSzZlkG5MyJe333MRo6syu/08w40tXHL/YbU5kSCN2YJaj3s0yZwxlEkYWS NdWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=eovIoKsLh+X8F80ZqvoQ/K6quxM5fHADO6wFiNQ33Ns=; b=q2e7fgWNJuleVV40rJ+/IyjkjtENP6/Y/32XZtZQT2JW5WIFcPqEsxHw0Z3uibVg8g 98Ltk+8Ea6Uajp+EYFlokKXI+GeZc/IE343lPMknKL+cVyhUCJCMbMZGQ1aUtO8mhGML xPIuxKvtZkqgXo2YqFrGJ8gE9xgdfUDvT+3AXVW9PY4RQtkQRBhPfI68IIbAmqy2ySbm C99yq/CNVmNQUo12kqk58wI+WgNaHnBq6o1csx2LBRkcu31e/QlduRgVVyn4XY0B2Vka eDkK5xPo4n/mVCxGf38kKrX4J5szF2CO76Kqmj6HN5XKrzgd/B4p0uZVwgQyRxZLDI4x UKlQ== X-Gm-Message-State: AElRT7E31McLegdpIjz7pXFhZpny1rRNDZOsLDJrnlreIG0RHg13Stqe 1bBWtef7X3mRlBSZitEW756OcKrIB8gAx3ZGBEWzxQ== X-Google-Smtp-Source: AIpwx49HtnaNqK4Ad7ZT2F12rCHmsEmXc08Mn40Yj2I12LzD2bmkUcM3j8YsSATL9vNbT8Z9dmbmqsfF9GoC4TKt1iQ= X-Received: by 10.31.194.3 with SMTP id s3mr2208486vkf.118.1522241726845; Wed, 28 Mar 2018 05:55:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.168.211 with HTTP; Wed, 28 Mar 2018 05:55:26 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= Date: Wed, 28 Mar 2018 14:55:26 +0200 Message-ID: To: Samad Sajanlal , Bitcoin Protocol Discussion Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, FROM_EXCESS_BASE64, RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Soft Fork Activation & Enforcement w/o Signaling? 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: Wed, 28 Mar 2018 12:55:28 -0000 Yes, you can activate softforks at a given height. I don't see any reason why you couldn't rebase to 0.16 directly. The block version bumping was a mistake in bip34, you don't really need to bump the version number. In any case, I would recommend reading bip34 and what it activates in the code. IIRC the last thing was bip65. On Wed, Mar 21, 2018 at 11:04 PM, Samad Sajanlal via bitcoin-dev wrote: > Is it possible to activate soft forks such as BIP65 and BIP66 without prior > signaling from miners? I noticed in chainparams.cpp that there are block > heights where the enforcement begins. > > I understand this is already active on bitcoin. I'm working on a project > that is a clone of a clone of bitcoin, and we currently do not have BIP65 or > BIP66 enforced - no signaling of these soft forks either (most of the > network is on a source code fork of bitcoin 0.9). This project does not and > never intends to attempt to replace bitcoin - we know that without bitcoin > our project could never exist, so we owe a great deal of gratitude to the > bitcoin developers. > > If the entire network upgrades to the correct version of the software (based > on bitcoin 0.15), which includes the block height that has enforcement, can > we simply skip over the signaling and go straight into > activation/enforcement? > > At this time we are lucky that our network is very small, so it is > reasonable to assume that the whole network will upgrade their clients > within a short window (~2 weeks). We would schedule the activation ~2 months > out from when the client is released, just to ensure everyone has time to > upgrade. > > We have been stuck on the 0.9 code branch and my goal is to bring it up to > 0.15 at least, so that we can implement Segwit and other key features that > bitcoin has introduced. The 0.15 client currently works with regards to > sending and receiving transactions but the soft forks are not active. I > understand that activating them will segregate the 0.15 clients onto their > own fork, which is why I'd like to understand the repercussions of doing it > without any signaling beforehand. I also would prefer not to have to make > intermediate releases such as 0.10, 0.11.. etc to get the soft forks > activated. > > Another related question - does the block version get bumped up > automatically at the time that a soft fork activates, or is there additional > stuff that I need to do within the code to ensure it bumps up at the same > time? From what I saw in the code it appears that it will bump up > automatically, but I would like some confirmation on that. > > Regards, > Samad > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >