08:17:47 <binaryFate> <tevador> I think the hashrate there is calculated from the difficulty, so it's the running average over the last 720 blocks <-- the most extremes quantiles are not part of computation though, no? So if a block is particularly fast or slow, the difficulty (and hashrate) will appear not to change as the block is "ignored"
08:19:37 <binaryFate> selsta ^ the computed hashrate may not always appear to change from one block to another
10:45:59 <selsta> binaryFate: yep but let’s say suddenly half the hashrate drops, would it take ~720 blocks for it to fully update?
10:59:26 <sech1> 675 blocks
11:00:29 <sech1> 75 blocks before difficulty starts to react and then 600 more to fully adjust (out of 720, top and bottom 60 are discarded)
11:02:38 <sech1> 75 is because there's also 15 block lag before it takes 720 blocks to calculate the difficulty
11:08:01 <selsta> ok thanks I understand it now
11:14:26 <tromp> tevador: where on page 88 of https://github.com/zcash/zips/blob/master/protocol/protocol.pdf do you see distinct index requirement?
12:54:29 <tevador> tromp: https://i.imgur.com/9FkISpe.png
12:55:33 <tromp> that's describing the gernealized birthday problem
12:56:39 <tromp> the equihash conditions should all be specified following "A valid Equihash solution is t"
12:57:31 <tromp> i think for a spec this is ambiguous at best
12:58:10 <tromp> did you check what zcash verification code does?
13:02:05 <tevador> https://github.com/zcash/zcash/blob/master/src/crypto/equihash.cpp#L755
13:03:41 <hyc> so zcash has abandoned ProgPoW?
13:03:52 <hyc> and they want to move off equihash still?
13:05:36 <tevador> hyc: zcash has been using equihash since the beginning, it's ethereum which considered progpow
13:06:21 <hyc> yes...
13:06:31 <hyc> but zcash had been talking about moving off equihash for a while now
13:06:53 <hyc> although then it seemed they gave up on the idea of changing, and were just going to live with ASICs
13:07:11 <hyc> and ProgPoW was one of the aglos they were looking at switching to
13:10:22 <tevador> AFAIK they considered changing their PoW in 2018 when the first ASICs appeared, but they decided not to do anything
13:17:45 <tromp> you're right; they do enforce distinct indices.  they actually do 2^17-1 comparisons to check.
13:19:35 <tromp> if allowing identical indices in your equix only produces a tiny fraction of additional solution, then i see no point in forbidding them
13:57:19 <tevador> tromp: 128k comparisons? I'd like to see their solution verification time...
14:51:15 <tromp> correction; that's (512 choose 2) = 2^17-2^8 comparisons. still close to 128K.
14:54:33 <tromp> ZCash PoW solution also dominates header size at 1344 bytes
14:55:03 <tromp> how big is Monero header?
14:57:01 <sech1> Empty block is around 115 bytes
15:02:29 <tevador> I'm not sure why exactly they chose Equihash 200,9 - there are much better options with faster verification and smaller proofs
15:10:26 <tromp> because they rushed the launch and thought other variants might take too many seconds per attempt
15:11:24 <tromp> also they (actually, the Equihash authors) badly misjudged the space required to solve 200,9
15:12:28 <tromp> by the time they held the miner implementation challenge, they were alrd pretty much committed to 200,9
15:13:20 <tromp> the entries in that contest showed that it required far less memory than the 1GB they imagined
15:46:40 <moneromooo> Empty block is more than < 100 bytes IIRC.
15:47:24 <moneromooo> I see a recent one at 96 bytes (2112514).
15:50:22 <sech1> Yes, it's 96 bytes or more, depending on extra nonce size.
15:57:25 <UkoeHB_> that's the miner tx size; maybe 'block size' isn't taking into account the header properly
15:58:17 <UkoeHB_> the header should be at least 42 bytes I think
16:01:45 <moneromooo> Oh. Good point...