From: Peter Todd <pete@petertodd•org>
To: Tier Nolan <tier.nolan@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Version bits proposal
Date: Wed, 27 May 2015 06:15:16 -0400 [thread overview]
Message-ID: <20150527101516.GB25814@savin.petertodd.org> (raw)
In-Reply-To: <CAE-z3OVAKyppLVEWR=qNX-_p5yVAj_0Y7Kw76o4qaywf2DKtVw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1445 bytes --]
On Wed, May 27, 2015 at 10:35:03AM +0100, Tier Nolan wrote:
> I think it would be better to have the deadlines set as block counts. That
> eliminates the need to use the median time mechanism.
The median time mechanism is basically a way for hashing power to show
what time they think it is. Equally, the nVersion soft-fork mechanism is
a way for hashing power to show what features they want to support.
Block counts are inconvenient for planning, as there's no guarantee
they'll actually happen in any particular time frame, forward and back.
There's no particular incentive problems here - the median time clearly
shows support by a majority of hashing power - so I don't see any reason
to make planning more difficult.
> The deadline could be matched to a "start-line". The definition would then
> be something like
>
> BIP 105
> Start block: 325000
> End block: 350000
> Activation: 750 of 1000
> Implication: 950 of 1000
> Bit: 9
>
> This would allow creation of a simple table of known BIPs. It also keeps
> multiple users of the bit as strictly separate.
If you assume no large reorganizations, your table of known BIPs can
just as easily be a list of block heights even if the median time
mechanism is used.
If you do assume there may be large reorganizations you can't have a
"simple table"
--
'peter'[:-1]@petertodd.org
000000000000000001643f7706f3dcbc3a386e4c1bfba852ff628d8024f875b6
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
next prev parent reply other threads:[~2015-05-27 10:15 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-27 1:48 Pieter Wuille
2015-05-27 2:31 ` Douglas Roark
2015-05-27 3:46 ` Luke Dashjr
2015-05-27 3:51 ` Jorge Timón
2015-05-27 9:35 ` Tier Nolan
2015-05-27 10:15 ` Peter Todd [this message]
2015-05-27 11:26 ` Tier Nolan
2015-05-27 22:52 ` Sergio Lerner
2015-05-28 1:05 ` Patrick Strateman
2015-05-28 7:51 ` Christian Decker
2015-05-28 8:11 ` Adam Back
2015-06-01 14:50 ` Potter QQ
2015-05-27 10:15 ` Jorge Timón
2015-06-03 20:42 ` Pieter Wuille
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=20150527101516.GB25814@savin.petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=tier.nolan@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