public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Jorge Timón" <jtimon@jtimon•cc>
To: Samad Sajanlal <samad.sajanlal@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Soft Fork Activation & Enforcement w/o Signaling?
Date: Fri, 30 Mar 2018 22:52:50 +0200	[thread overview]
Message-ID: <CABm2gDpRY81cxyMmBnKyTefk=6d89YCxPVZjt3C2qwNq1sTK_g@mail.gmail.com> (raw)
In-Reply-To: <CAAQZUuCW+dijXgLOkDwjx8sCnhFbygqaT-0gLxAwx7EEx=VcaQ@mail.gmail.com>

Yes, in fact, you don't need to lose those bits like bitcoin by
imposing that the version is greater than that. But I guess just doing
the same is simpler.

On Thu, Mar 29, 2018 at 7:14 AM, Samad Sajanlal
<samad.sajanlal@gmail•com> wrote:
> 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
>> >
>
>


      reply	other threads:[~2018-03-30 20:52 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-21 22:04 Samad Sajanlal
2018-03-28 12:55 ` Jorge Timón
2018-03-29  5:14   ` Samad Sajanlal
2018-03-30 20:52     ` Jorge Timón [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CABm2gDpRY81cxyMmBnKyTefk=6d89YCxPVZjt3C2qwNq1sTK_g@mail.gmail.com' \
    --to=jtimon@jtimon$(echo .)cc \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=samad.sajanlal@gmail$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox