1 2015-09-24 00:00:13 <jtimon> rusty: but difficulty adapts to "enforce time", precisely using the median time
 2 2015-09-24 00:00:40 <sipa> well raw timestamp is easiest, then height, then mediantimepast
 3 2015-09-24 00:00:58 <sipa> jtimon: i don't understand what you're trying to say
 4 2015-09-24 00:01:12 <jtimon> rusty I understand your concern, I just diagree it is important
 5 2015-09-24 00:01:31 <sipa> softfork feature adoption and deployment are limited by human actions
 6 2015-09-24 00:01:53 <jtimon> ??
 7 2015-09-24 00:01:59 <gmaxwell> I am lost.
 8 2015-09-24 00:02:22 <sipa> gmaxwell: here is east
 9 2015-09-24 00:02:43 <rusty> jtimon: it's a human thing.  Getting authors who are invested in their BIP to consider its failure is difficult already.  I have already had this conversation with one such author.
10 2015-09-24 00:03:05 <rusty> jtimon: I am optimizing to reduce that barrier, by providing a strong recommendation and a table of values.
11 2015-09-24 00:03:36 <jtimon> I've been trying to discuss block.nTime vs medianTime vs height for a while in the mailing list, each of the options have unique advantages and disadvantages
12 2015-09-24 00:04:22 <gmaxwell> I thought we were talking about versionbits.
13 2015-09-24 00:04:38 <jtimon> rusty, any recommendation using dates can be trivially translatable to use height
14 2015-09-24 00:04:47 <rusty> jtimon: HOW?
15 2015-09-24 00:05:06 <jtimon> 10 min = 1 block
16 2015-09-24 00:05:30 <rusty> jtimon: yeah, that's trivial.  It's also wrong.
17 2015-09-24 00:05:33 <sipa> assuming no hashrate growth...
18 2015-09-24 00:05:45 <jtimon> it's not as exact as median time (which isn't exact either) and that's the main disadvantage of the height approach
19 2015-09-24 00:06:19 <rusty> jtimon: so, in practice, it's not trivial at all.  If I want to give at least 2 years for deployment, I need to double that number, to be conservative.
20 2015-09-24 00:06:33 <jtimon> block.nTime and median time have their own disadvantages
21 2015-09-24 00:06:48 <jtimon> why double?
22 2015-09-24 00:06:58 <sipa> gmaxwell: they (we?) are talking about whether versionbits' expiration time should be based on time, height, or mediantimepast
23 2015-09-24 00:06:59 <rusty> jtimon: why not?  You said it's "trivial", you figure it out.
24 2015-09-24 00:07:45 <rusty> jtimon: go back and look at historical block times, do the measurements and then do some future predictions based on the best information we have on hash rate, then supply a factor.
25 2015-09-24 00:07:48 <sipa> rusty: that would require a hashrate growth of 2^52 in a year :)
26 2015-09-24 00:08:06 <sipa> to have 210000 blocks in a year
27 2015-09-24 00:08:13 <sipa> eh, 105000
28 2015-09-24 00:08:15 <rusty> sipa: 2^26 maybe, timed right?
29 2015-09-24 00:08:42 <sipa> rusty: doubling every 2016 blocks, so every such window requires 1 week instead of 2
30 2015-09-24 00:08:52 <rusty> sipa: ah, good point.
31 2015-09-24 00:09:43 <gmaxwell> I don't think it matters all that much in reality. But the time is easier for people looking at the spec to reason about. What downside does the time have?
32 2015-09-24 00:09:45 <jtimon> anyway, as said I undesrtand the disadvantage
33 2015-09-24 00:09:59 <rusty> jtimon: I don't think you do, you keep calling the conversion trivial.
34 2015-09-24 00:10:20 <sipa> times also have the advantage of being beneficial to gmaxwell's sleep pattern
35 2015-09-24 00:10:35 <jtimon> yes, and then clarifying that it is not as exact as median time (which is not exact either)
36 2015-09-24 00:11:38 <rusty> jtimon: indeed, because of the 2016 block cadence, it's about Jan 1 to Jan 14.
37 2015-09-24 00:11:54 <rusty> jtimon: but nobody is going to screw up the calculation, since it's already a well-defined part of bitcoin.
38 2015-09-24 00:12:39 <gmaxwell> Is there are concern that miners will manipulate the timestamps to change the threshold point?
39 2015-09-24 00:13:08 <jtimon> we don't need perfection, we're supposed to be already conservative when picking the time frames
40 2015-09-24 00:14:22 <gmaxwell> Again I ask, what is the disadvantage in using the time?
41 2015-09-24 00:14:32 <rusty> jtimon: sure, but I can put a table of dates in the BIP.  I'd have to keep updating a table of expected block times.
42 2015-09-24 00:14:35 <jtimon> I mean, I'm thinking more about pre-hardfork activation periods than about the bit deprecation period, but I would like us to use the same for everything rule-activation related
43 2015-09-24 00:15:23 <gmaxwell> oh if you are thinking about the activation them the time is very much preferrable. In that case variations are unwelcome because I can't plan my sleep schedule around them.
44 2015-09-24 00:15:28 <jtimon> rusty: no, you would just explicitly say "take into account that blocks aren't always 10 minutes away" and maybe link to some historical data
45 2015-09-24 00:16:00 <gmaxwell> for timeout I don't really think one or the other really matters because you can just be conservative and use longer times.
46 2015-09-24 00:16:29 <gmaxwell> just block finding variance makes height not awesome for the activation.