From: Samad Sajanlal <samad.sajanlal@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: [bitcoin-dev] Soft Fork Activation & Enforcement w/o Signaling?
Date: Wed, 21 Mar 2018 17:04:35 -0500 [thread overview]
Message-ID: <CAAQZUuDEJeMFTxxJcgUEmTUQbxM_ZWkBD1k+UOvafsqbqj++Jg@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2142 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 5102 bytes --]
next reply other threads:[~2018-03-21 22:04 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-21 22:04 Samad Sajanlal [this message]
2018-03-28 12:55 ` [bitcoin-dev] Soft Fork Activation & Enforcement w/o Signaling? Jorge Timón
2018-03-29 5:14 ` Samad Sajanlal
2018-03-30 20:52 ` Jorge Timón
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=CAAQZUuDEJeMFTxxJcgUEmTUQbxM_ZWkBD1k+UOvafsqbqj++Jg@mail.gmail.com \
--to=samad.sajanlal@gmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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