Peter Todd [ARCHIVE] on Nostr: 📅 Original date posted:2015-05-27 📝 Original message:On Wed, May 27, 2015 at ...

📅 Original date posted:2015-05-27
📝 Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150527/2107dc0e/attachment.sig>;