From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Helder Garcia <helder.garcia@gmail•com>
Cc: "bitcoin-dev@lists•linuxfoundation.org"
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP0008 clarification
Date: Mon, 12 Feb 2018 22:26:47 -0500 [thread overview]
Message-ID: <x1rOm5WuZPrKyBLCBpEvK756G1XwBP0m4xnNbVSEwEI0kRqmgfikXUylnpR0Qnsn9Ek6IQ97dvcBZNWuq7b17CsfEpa1SYtDDnN4sHEMsYw=@protonmail.com> (raw)
In-Reply-To: <6EAA8D06-3A20-4BBA-BE2E-95B42BCCE7D3@gmail.com>
Good morning Helder,
>Hi,
>
> I’m trying to understand the process of signalling and activation of updates in bitcoin. Following BIP34, BIP9, I got into BIP8.
> In my understanding of what I read there, an update will be activated even if the threshold of 95% signalling is not reached in STARTED state, as soon as blockchain height is equal or higher than timeout_height.
> Is my understanding correct? If so, isn’t it a risk to activate a change even if you don’t have the majority of hash power accepting it?
Assuming the update is widespread among economic actors, only miners who do not follow the more stringent rules of the update will suffer, as their blocks will have a high probability of not following those rules and thus will be implicitly rejected by economic actors. Rational miners who follow the update, no matter how small their hash power share, would prefer the chain that economic actors will accept as real and would build only on blocks that follow updated rules strictly.
Indeed, the time from STARTED to ACTIVE simply serves to let miners upgrade their software, as a concession that in the real world we cannot safely deploy new software in a single day.
Regards,
ZmnSCPxj
prev parent reply other threads:[~2018-02-13 3:26 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-08 2:49 Helder Garcia
2018-02-13 3:26 ` ZmnSCPxj [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='x1rOm5WuZPrKyBLCBpEvK756G1XwBP0m4xnNbVSEwEI0kRqmgfikXUylnpR0Qnsn9Ek6IQ97dvcBZNWuq7b17CsfEpa1SYtDDnN4sHEMsYw=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=helder.garcia@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