Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 9614E13D5 for ; Wed, 21 Mar 2018 22:04:37 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-it0-f45.google.com (mail-it0-f45.google.com [209.85.214.45]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1BF3F4CC for ; Wed, 21 Mar 2018 22:04:37 +0000 (UTC) Received: by mail-it0-f45.google.com with SMTP id e195-v6so8801515ita.5 for ; Wed, 21 Mar 2018 15:04:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=M7tGvZUOSgcclsET4GBpM2QlSWyek2y4oJMZJ2xPg4M=; b=WMCRSAL1c/72Ex8SUZiT+onKkKnXTlSwquEnMUT4unyEkHjzz0vg7IGyl+qXTAPQTk FE4dd/MPbY/3Ed+oz/g5grzW+73FfUUDyKL8Jl93fGsJEqMU0yRQ3zIZyjlpJ9adUFGO T6foRT7wH7NuLaYIeC+NwJnjhbOt6fYbpN3/jssQBsPcW4bZxMq/NP/mLoCaTOZjXNYX LkFX39ciOxQxBy3cdZGm6TLBfPj6X1MEEw/zqNmvs1eCW690zCfnLreqB2APz3QN3Au6 F5sc8YH8v+tR0U8CPrfio+doIzxQF5Mlk+YmF/7FYUOmtTdwztekqt68pbtGqczqXuS0 0GnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=M7tGvZUOSgcclsET4GBpM2QlSWyek2y4oJMZJ2xPg4M=; b=fh6u2cKlj6y62iNaO4K61riPxpyyxWVsqEu6mSEyl0IMYFs3CiabTiO6uFVzLRzxuD 2y/S32QGIL6hS4VcswpNiEiNNbMxbkvHI/q/94xU6CxLYGCUsc+PM6miT6xrDdUNE/OA FVdSSBzmADORbdtxQLWxWSypOnqFx3A53xKm2KZFlxgn1X5YDgg2kfHADTa+SeElSdTv ny5u4dxfiC5lSN7zqeIxeVV0KH2dgIyi0SEdeNY3O1YJ0vOStBBBp/3WyN34XqibvTsb G4sfDhmCJtHW6yjAnzHKNe1sqId6sSX/2DSPTVReLX7/EE1BFujr/huiduA8jW5uS3lG cvdA== X-Gm-Message-State: AElRT7GwG6qw60/HNczu028iNffMHiUzUa5zqDS+taM9BBHLQYUR9mhD pC8pWhPSNaPAeGe9NJj9jJiHkAMjYXnJhSR5Hz1V7g== X-Google-Smtp-Source: AG47ELtXMQWyboGZqfAWaLS44Qbx1euSQJKGeRkcMIvN/YvVO2+YOSUCCr0UBfWp/DhPgZgFXegnONPU+pBmGYVHa7k= X-Received: by 2002:a24:ef46:: with SMTP id i67-v6mr6377649ith.51.1521669876239; Wed, 21 Mar 2018 15:04:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.140.147 with HTTP; Wed, 21 Mar 2018 15:04:35 -0700 (PDT) From: Samad Sajanlal Date: Wed, 21 Mar 2018 17:04:35 -0500 Message-ID: To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary="0000000000007052490567f36057" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Thu, 22 Mar 2018 01:46:44 +0000 Subject: [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, 21 Mar 2018 22:04:37 -0000 --0000000000007052490567f36057 Content-Type: text/plain; charset="UTF-8" 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 --0000000000007052490567f36057 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Is it possible to act= ivate soft forks such as BIP65 and BIP66 without prior signaling from miner= s? I noticed in chainparams.cpp that there are block heights where the enfo= rcement begins.=C2=A0

I understand this is already acti= ve on bitcoin. I'm working on a project that is a clone of a clone of b= itcoin, 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 o= f bitcoin 0.9). This project does not and never intends to attempt to repla= ce 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 sof= tware (based on bitcoin 0.15), which includes the block height that has enf= orcement, can we simply skip over the signaling and go straight into activa= tion/enforcement?

At this time we are lucky that our network i= s very small, so it is reasonable to assume that the whole network will upg= rade 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 e= veryone has time to upgrade.

We hav= e been stuck on the 0.9 code branch and my goal is to bring it up to 0.15 a= t least, so that we can implement Segwit and other key features that bitcoi= n has introduced. The 0.15 client currently works with regards to sending a= nd receiving transactions but the soft forks are not active. I understand t= hat activating them will segregate the 0.15 clients onto their own fork, wh= ich 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 intermed= iate releases such as 0.10, 0.11.. etc to get the soft forks activated.

Another re= lated 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 t= o do within the code to ensure it bumps up at the same time? From what I sa= w in the code it appears that it will bump up automatically, but I would li= ke some confirmation on that.

Regards,
Samad


--0000000000007052490567f36057--