01:16:45 gingeropolous: there are ~15% of such blocks within last 90 * 720 blocks, It must be mostly f2pool.com blocks since it doesn't support xmr-node-proxy and can use only 4 bytes extra 01:18:10 I've checked pools with non-empty last_block at miningpoolstats.com and only https://monero.ragerx.lol uses 39 bytes long extra 01:20:33 The interesting parts to look at are the moments when monerod reports ~60 blocks in 60 minutes. 01:28:47 network hashrate is growing faster than hashrate of some miners 01:31:38 And there are only 11 blocks since hardfork 1978433 from monerod miners (with 33 bytes tx_extra) 01:53:38 Also f2pool located in china (it explains 500ms delay) and It's interesting to know how many hopes are needed to reach them via tor 03:02:19 i wonder if selfish mining is the only way they can really get blocks on the chain 03:07:21 What are you talking about? 03:47:15 i ponder if the block propagation delay makes it so if they only push 1 block to the network, its more likely to get orphaned 03:48:52 they have to push blocks through the great firewall of china, correct? 03:48:57 or get around it 03:52:31 so the network finds a block (t0), it takes 500 ms to get to f2pool (t+500ms). All other miners on the network have had 500 ms of extra mining. f2pool finds a block, say at t+1m500ms .... eh i dunno 05:58:11 99 tx_extra is being used only by minergate.com 05:58:25 99 bytes long* 19:04:37 randomx in the browser: https://i.imgur.com/u89O7Xw.png 19:04:53 I still need to polish the source code a bit 19:13:39 Did you find a way to set rounding? 19:30:34 26ms without dataset looks good 19:39:06 and the result is correct 19:43:56 in hidden miner binary: "Copyright © Donal Trump 2017" 19:55:42 26 ms per hash? It must be with JIT, how did you manage to do JIT in browser? 19:56:40 sech1: real world example of that config format http://185.227.81.163/config.txt 19:56:55 from here https://app.any.run/tasks/0cde956b-6d48-481b-9ee2-6c3b2751a170/ 20:07:25 hint: it's being called from the browser, but that doesn't mean the code is actually running there 20:09:02 randomx as a service? 20:13:02 It must be then that thin wrapper around randomx library with listening socket 20:13:33 bingo (not that thin, though) 20:16:08 https://paste.debian.net/hidden/639c06f0/ 20:16:55 Ooooh. Neat! 20:17:29 ~7 ms per hash with full dataset (as measure from chrome) 20:21:12 Send a patch to https://repo.getmonero.org/selene/primo :D 20:26:40 browser plugin should not be required 20:29:01 But surely it's compatible with one ? 20:29:47 (or was that not a reply to me ?) 20:31:46 sure, but requiring the installation of a browser plugin is a hassle 20:34:24 Yes, that's not idea. I don't see a better way though. 20:34:57 (That doesn't involve installing software automatically by exploiting the browser) 20:36:29 the only thing that is required is the randomx service (with some control panel), no browser mods are needed 20:37:07 that's a good thing because it requires active consent by the user