--- Log opened Tue Jun 15 00:00:38 2021
00:54 < elichai2> roconnor: Yeah I agree, and it's only 12K blocks down, so it's really weird
01:03 < gmaxwell> maybe your RNG sucks.
01:04 < gmaxwell> Not an uncommon problem.
01:04 < gmaxwell> Also if you're using mod you'll bias your randomness. You must use rejection sampling.
01:04 < gmaxwell> also if you're searching on times you might be getting messed up by non-monotone timestamps.
03:53 < elichai2> gmaxwell: non-monotone timestamps are a thing? I thought bitcoin doesn't allow a block with a timestamp before its parent
03:54 < elichai2> (as for the rng I'm currently using a common rust library for this, but I can try reading from `getrandom` and then doing rejection sampling)
03:55 < gmaxwell> haha well thats your problem.
03:56 < gmaxwell> Timestamps can be non-monotone yes.
03:56 < gmaxwell> Or at least it's a problem.
03:59 < gmaxwell> ot
04:00 < gmaxwell> er. It's also the case that the block timestamps are only kind of roughly related to when the block was found, but I dunno if that would produce an interesting bias in your results.
04:00 < gmaxwell> (though it's part of why they're non-monotone)
04:01 < gmaxwell> elichai2: as far as your expectation, bitcoin couldn't do that AND impose a maximum time ahead of realtime without creating a vulnerablity.
04:03 < gmaxwell> elichai2: imagine time has to be monotone. Imagine blocks can't be more than 2 hours in the future (as is the case...).  Now an attacker sets his time to the absolute highest value, and for the next two hours everyone has to use the same timestamp as him or give a even more false time. And nodes with less synced clocks will be rejecting blocks as too far in the future left and right.
04:03 < gmaxwell> so there is only a very weak criteria that each blocks timestamp has to be greater than the median of the prior 11 blocks.
04:03 < elichai2> yeah that sounds like a vulnerability
04:04 < elichai2> but then how do I define "next block" if it's non monotone? like sorting the timestamps seems weird because it will change the order of the blocks
04:04 < gmaxwell> in any case, with your search, you can track for every block what that median of last 11 is-- *that* figure is monotone.
04:04 < elichai2> I guess timestamps from the headers just aren't a great metric here, but I don't have access to another metric
04:05 < gmaxwell> the blocks are in order. but yeah you really cant trust the header times. Maybe someone publishes a database of observations.
04:05 < elichai2> btw, if I just sort the timestamps I get avg of 565 seconds
04:05 < elichai2> argh *556
04:06 < gmaxwell> well that sounds plausable. Bitcoin hashrate has been increasing over its whole life, so that lowers the average.
04:08 < elichai2> yeah that's pretty close to the 9.5 minutes average per block I seem to remember
04:15 -!- belcher [~belcher@user/belcher] has joined #secp256k1
05:54 < roconnor> That's sorting and excluding the first 40000 blocks?
06:08 -!- belcher [~belcher@user/belcher] has quit [Remote host closed the connection]
06:10 -!- belcher [~belcher@user/belcher] has joined #secp256k1
06:18 < elichai2> yes
06:18 < roconnor> 565 is the number you got before.
06:59 < roconnor> oops you said 556.
07:14 < sipa> elichai2: or you can monotonize the timestamps by using the MedianTimePast of each block
07:37 < roconnor> or use the time that blocks were recorded as received at?
07:44 < sipa> that would be even better, if you can get access to the data...
09:29 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Read error: Connection reset by peer]
09:30 -!- luke-jr [~luke-jr@user/luke-jr] has joined #secp256k1
10:41 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
10:43 -!- luke-jr [~luke-jr@user/luke-jr] has joined #secp256k1
13:21 -!- roconnor [~roconnor@host-184-164-16-124.dyn.295.ca] has quit [Remote host closed the connection]
13:54 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Read error: Connection reset by peer]
13:55 -!- luke-jr [~luke-jr@user/luke-jr] has joined #secp256k1
16:04 -!- roconnor [~roconnor@host-184-164-16-124.dyn.295.ca] has joined #secp256k1
21:38 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 268 seconds]
21:50 -!- belcher [~belcher@user/belcher] has joined #secp256k1
--- Log closed Wed Jun 16 00:00:39 2021