From: "Jorge Timón" <jtimon@jtimon•cc>
To: Shuning Hong <hongshuning@gmail•com>,
Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP - Block size doubles at each reward halving with max block size of 32M
Date: Wed, 18 Nov 2015 11:15:54 +0100 [thread overview]
Message-ID: <CABm2gDo30EhWmreaFBB81H6mvUwO=KpWz_c+uavsG1KBYGLgaw@mail.gmail.com> (raw)
In-Reply-To: <CABEog-XUNt9kDS7Mc0XYFjm5ePUT0m1YaAoG9VypTCiGLBongQ@mail.gmail.com>
On Wed, Nov 18, 2015 at 10:13 AM, Shuning Hong <hongshuning@gmail•com> wrote:
> 2015-11-15 20:16 GMT+08:00 Jorge Timón <bitcoin-dev@lists•linuxfoundation.org>:
>> The time threshold must be set enough in the future to give users time to upgrade. But we can perceive miners' adoption, so if the system knows they haven't upgraded, it should wait for them to upgrade (it would be nice to have an equivalent mechanism to wait for the rest of the users, but unfortunately there's none).
>
> If the majority of the miners never upgrade, how could we treat that
> BIP? Wait forever?
Assuming it was deployed as an uncontroversial hardfork as recommended
in BIP99, the deployment would use versionbits (BIP9) and the hardfork
would timeout.
But this timeout would clearly signal that either the minimum
activation threshold wasn't giving enough time for all users to
upgrade (apparently miners didn't had time) or the hardfork is not
really an uncontroversial hardfork but rather a schism one. Then,
assuming some people still want to deploy it as a schism hardfork,
bip99 recommends using only a mediantime threshold without versionbits
nor miner upgrade confirmation.
next prev parent reply other threads:[~2015-11-18 10:15 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-12 23:47 John Sacco
2015-11-13 2:56 ` Chun Wang
2015-11-13 3:37 ` John Sacco
2015-11-13 7:49 ` Btc Drak
2015-11-13 9:50 ` John Sacco
2015-11-13 10:52 ` Luke Dashjr
[not found] ` <1447430469019.e0ee1956@Nodemailer>
2015-11-13 22:28 ` Luke Dashjr
2015-11-14 0:02 ` digitsu
2015-11-14 9:31 ` Adam Back
2015-11-14 10:52 ` Jorge Timón
2015-11-14 21:11 ` Luke Dashjr
[not found] ` <CADZB0_Z3Kf4GW0VATjb10kJF0aFgyFOcqX_=y+LFoUpsi+TRUA@mail.gmail.com>
2015-11-14 21:27 ` Luke Dashjr
2015-11-15 12:16 ` Jorge Timón
[not found] ` <CABEog-XUNt9kDS7Mc0XYFjm5ePUT0m1YaAoG9VypTCiGLBongQ@mail.gmail.com>
2015-11-18 10:15 ` Jorge Timón [this message]
2015-11-13 6:39 ` Luke Dashjr
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='CABm2gDo30EhWmreaFBB81H6mvUwO=KpWz_c+uavsG1KBYGLgaw@mail.gmail.com' \
--to=jtimon@jtimon$(echo .)cc \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=hongshuning@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