Re: [bitcoin-dev] Soft Fork Activation & Enforcement w/o Signaling?

From: Samad Sajanlal <samad.sajanlal@gmail•com>
To: "Jorge Timón" <jtimon@jtimon•cc>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Soft Fork Activation & Enforcement w/o Signaling?
Date: Thu, 29 Mar 2018 00:14:42 -0500	[thread overview]
Message-ID: <CAAQZUuCW+dijXgLOkDwjx8sCnhFbygqaT-0gLxAwx7EEx=VcaQ@mail.gmail.com> (raw)
In-Reply-To: <CABm2gDq2pa_8T7Xhniuyh86eTi=PmSA_t=2Z0nYp1LhN=zc_NA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3568 bytes --]

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ón <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@lists•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 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
> >
>

[-- Attachment #2: Type: text/html, Size: 4622 bytes --]