Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id DA96E978 for ; Thu, 29 Mar 2018 05:14:44 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f176.google.com (mail-io0-f176.google.com [209.85.223.176]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 85FC0163 for ; Thu, 29 Mar 2018 05:14:43 +0000 (UTC) Received: by mail-io0-f176.google.com with SMTP id o4so6204947iod.3 for ; Wed, 28 Mar 2018 22:14:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Cc4GTKlvSJWf2U/IMc5v0ItK0bOMc7ZGpXVXwt88iPw=; b=AvRO9hmexg9HeIHAIKPFlSkcJu+IFkqQe6GvG1XKmfkWEpPT5VqLL6WEVlfuzDw0Oo Gsg/0izW32gdz59geK+hqExbQqpXRraPD/cRSWNdjZpb4xBwk+ekEDTEidVsH7UfgHmU RWjMksAwv25WuILbkXcDR3fQGBzFD3PrMw9QHxakZg2rR0o8XELH1Nd8oLdbqdfq6AKa O+/OTsfEqwm3XSjd1Q+vhCB2lnMsOOP3gzMgHsnTT58cI0P8U5Zu0qPrxJW5e7HawKGX UihJvSKhwN5tBOLKogAulLA85sQUBEm2GBT8UuH3pfi4I7bPSVKQK59kmUggxKyU6tvt xPQA== 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:cc; bh=Cc4GTKlvSJWf2U/IMc5v0ItK0bOMc7ZGpXVXwt88iPw=; b=KRBhLGGofGld9IqZmHB+I0OKPxJLufbRxpEyfwFnNU4p6FZGncC/CgJQeaKx8lxxEk Vvc7oYCEseJIfgzvXferddvcXVs+gsX8qBXzGMGApPpXQtDKhclX6uxGEAhb/eIMSpwi P3XEjhcMbYIOsBl4UOOsWXaKrrOEwMVDfIXWx9nyA/EUv0im2H2KqaIv9y7TAu5hdnSq 7OBjFL0q15x++z8Owq58OPLq+URVyRXZzZdyYnZGWtuSsXIQsmzjJUxC+UdW11lXPWTT 6EzXkSh8lvQJOHhGkzYd6if9zSuUCVWw049NFReBPQQWnI10A1pdjabIc8ZcaS6yvAxY gVJA== X-Gm-Message-State: AElRT7GclOJyI5fUS8Nx+PUz9bUgDeh0n3/PEQBoq951hDgporibkH9E K4TI3a1O/+j43E3vJWbl4Ykhcp2k8JUNmFX4whwkFQ== X-Google-Smtp-Source: AG47ELvENMVC3raNW+t7FUpB5xgtAS9lnN+HFMP1HFaFLnhstB2F2hcewR7wNKWpUQXIGAuV3FWFQNY1epJRsrP8vsU= X-Received: by 10.107.16.65 with SMTP id y62mr50189773ioi.213.1522300482816; Wed, 28 Mar 2018 22:14:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.140.147 with HTTP; Wed, 28 Mar 2018 22:14:42 -0700 (PDT) In-Reply-To: References: From: Samad Sajanlal Date: Thu, 29 Mar 2018 00:14:42 -0500 Message-ID: To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= Content-Type: multipart/alternative; boundary="001a113f2256850efb056886333a" 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, 29 Mar 2018 18:16:24 +0000 Cc: Bitcoin Protocol Discussion 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: Thu, 29 Mar 2018 05:14:45 -0000 --001a113f2256850efb056886333a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Excellent - Thanks for your response Jorge. This helps us plan out the future upgrades properly. Since I see 0.15 and 0.16 use block versions as 0x20000000, whereas the current deployed codebase (based on bitcoin 0.9.4) makes versions 0x00000002 (as seen by a 0.15 client), it appears safe to activate soft forks which require a minimum of version 3 and 4 blocks (0x00000003 and 0x00000004, respectively). Would you agree? On Wed, Mar 28, 2018 at 7:55 AM, Jorge Tim=C3=B3n wrote: > 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 bloc= k > > heights where the enforcement begins. > > > > I understand this is already active on bitcoin. I'm working on a projec= t > > 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 t= he > > 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 doin= g > it > > without any signaling beforehand. I also would prefer not to have to ma= ke > > 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 sa= me > > 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 > > > --001a113f2256850efb056886333a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Excellent - Thanks for your response Jorge. This help= s us plan out the future upgrades properly.
Since I see 0.15 and 0= .16 use block versions as 0x20000000, whereas the current deployed= codebase (based on bitcoin 0.9.4) makes versions 0x00000002=20 (as seen by a 0.15 client), it appears safe to activate soft forks which re= quire a minimum of version 3 and 4 blocks (0x00000003 and 0x0000000= 4, respectively). Would you agree?

On Wed, Mar 28, 2018 at 7:= 55 AM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote:
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
<bitcoin-dev@li= sts.linuxfoundation.org> 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 blo= ck
> heights where the enforcement begins.
>
> I understand this is already active on bitcoin. I'm working on a p= roject
> that is a clone of a clone of bitcoin, and we currently do not have BI= P65 or
> BIP66 enforced - no signaling of these soft forks either (most of the<= br> > network is on a source code fork of bitcoin 0.9). This project does no= t and
> never intends to attempt to replace bitcoin - we know that without bit= coin
> 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 u= p 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 t= o
> sending and receiving transactions but the soft forks are not active. = I
> understand that activating them will segregate the 0.15 clients onto t= heir
> 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 m= ake
> 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 addi= tional
> stuff that I need to do within the code to ensure it bumps up at the s= ame
> 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@l= ists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--001a113f2256850efb056886333a--