01:06:32 * coinstudent2048[ < https://matrix.org/_matrix/media/r0/download/matrix.org/QaNwQbpXOBMixXTgzxqtEvMt/message.txt > 01:12:54 coinstudent2048[, no idea really how it was decided. It was originally 0.3 xmr per block, but then block time was increased to 2 minutes, so it grew to 0.6. So I always think its better to say 0.3 xmr per block minute 01:13:05 because, who knows, at some point blocks could get longer again 01:38:05 gingeropolous: Yeah I think it's better to say 0.3 xmr per block minute. From what I read, the increase to 2 minutes is trade-off between fast transactions and scalability (blockchain grows slower) + stability when Monero becomes popular (less 'orphans'). I don't understand much of these details, but my questions are answered. Thanks! 01:41:33 * gingeropolous: Yeah now I think it's better to say 0.3 xmr per block minute. From what I read, the increase to 2 minutes is trade-off between fast transactions and scalability (blockchain grows slower) + stability when Monero becomes popular (less 'orphans'). I don't understand much of these details, but my questions are answered. Thanks! 01:43:04 a key reason to increase to 2 minutes was to reduce orphan rate 01:45:28 as for 1 minute blocks making the blockchain smaller, I don't see 2 150 kB blocks being smaller than 1 300 kB block 01:46:09 I could easily be missing something 01:49:06 No I read that the 2 minute blocks make "blockchain grow slower", but again I am not sure; I am not well-versed in this. 01:50:52 * gingeropolous: Yeah now I think it's better to say 0.3 xmr per block minute. From what I read, the increase to 2 minutes is trade-off between fast transactions and (scalability (blockchain grows slower) + stability when Monero becomes popular (less 'orphans')). I don't understand much of these details, but my questions are answered. Thanks! 01:53:45 yes, 2min blocks reduce the rate of orphaned blocks 07:02:32 Will growing block sizes potentially increase the number of orphaned blocks again? 09:08:03 I doubt it. block size doesn't really affect mining rates 09:09:42 block propagation is slower and miner with low network bandwidth will get more orphan blocks 09:09:48 I mean miner nodes 09:10:26 maybe. most blocks are fluffy blocks 09:13:14 My fork will have 30 second blocks (trading orphans for better game playability) so we can find out (though how network size affects that is unclear). 09:14:01 your fork? 09:14:18 I forked monero. 09:14:54 (to make a game on a chain, not a straight coin) 17:49:30 hmm, I thought the OpenCL code for RandomX was still radeon-specific 17:51:12 there's generic OpenCL code too, it works on NVIDIA 19:29:00 hyc: Does the advent of fluffy blocks mean block time could be reduced again? 19:29:33 If you can get deterministic transaction ordering, e.g. by fee, and pre-emptively sync mempools, it seems like you could get block times arbitrarily low 19:29:48 since you would only need the header and the delta from the target node's mempool 19:31:10 (i.e. if I know my neighbor's mempool at time T, I only need to send the delta from now to time T, and any "weird" transactions I noticed, and he'd figure it out) 19:37:08 If a scammer mines (first) a block with tx that double spends an output in a tx that the rest of the miners have, it doesn't matter does it. 19:37:34 "it doesn't matter" referring to "deterministic transaction ordering, e.g. by fee, and pre-emptively sync mempools".