11:36:48 <sech1> @hyc my hacked RandomX dataset node didn't survive epoch change and banned all peers because it didn't update the dataset for some reason (but it did update the cache). How do you look if I rewrite rx_slow_hash and simplify its interface?
11:37:33 <sech1> I want to have something like "void rx_slow_hash(const hash* main_seedhash, const char *seedhash, const void *data, size_t length, char *result_hash)"
11:37:53 <sech1> main_seedhash would always point at current consensus chain seed hash
11:38:23 <sech1> and it would have a dedicated cache/dataset for main_seedhash, and a secondary cache for everything else
11:39:35 <sech1> and dedicated dataset could be turned on with command line parameter or an env variable
11:39:52 <sech1> and of course it would be created when mining starts
11:40:19 <hyc> you mean to create two datasets when mining starts?
11:40:25 <hyc> or to always have the main dataset?
11:40:25 <sech1> no, just one
11:40:32 <sech1> mining always mines on consensus chain
11:40:49 <hyc> ah ok
11:40:54 <sech1> I don't want rx_slow_hash to know anything about height, alt/non at and other stuff
11:41:00 <sech1> it only needs to know seed hash
11:41:05 <sech1> and the "reference" seed hash
11:41:29 <hyc> Yeah, if you can simplify things, that would be great. it's definitely ugly in there.
11:42:28 <sech1> yeah
11:42:41 <sech1> I managed to reduce block rebroadcast delay to sub 0.1s on most blocks
11:42:55 <sech1> and 0.01s for RandomX hash is now noticeable :D
11:43:53 <sech1> you can see what I did in https://github.com/SChernykh/monero/tree/block_verify_speedup
11:44:07 <sech1> mainly https://github.com/SChernykh/monero/commit/f9c21cbb1e518fbbd0568fe82e84f31f282bfac4
11:46:11 <sech1> the worst rebroadcast delay I saw so far was 0.14s on https://p2pool.io/explorer/block/2773376 - but that block was not only full, but full with 172 (!!!) transactions
11:46:24 <sech1> and before this fix, it was well over 1 second for such blocks
11:58:31 <\x> when monero fibre sech1
11:58:54 <\x> https://bitcoinfibre.org/
12:00:53 <hyc> sech1: so that speedup is from using dataset for verification?
12:03:38 <hyc> hm no, that commit has nothing to do with rx-slow-hash, nevermind
12:04:31 <sech1> that speedup is from not doing the same RingCT check for second time :D
12:04:53 <sech1> monerod checks it already when a transaction is added to the mempool
12:10:10 <hyc> when does the cache expire?
12:10:23 <hyc> should be after the block is accepted i suppose
12:46:21 <sech1> cache doesn't expire, it's just deleting old entries
12:46:35 <sech1> there's a ring buf of 8192 entries for this
12:46:56 <sech1> block accepted is not a good point to clear the cache because some transactions can still remain in mempool
12:48:07 <sech1> oh, and since the cache is storing hashes of data, not data itself, it must use cryptographically secure hash algo to be safe from collision attacks
12:48:20 <sech1> it uses cryptonote::get_blob_hash which is keccak
13:30:03 <hyc> why would a tx in a block remain in the txpool? I can see that a reorg'd block would dump all its txs back into the txpool
13:30:49 <sech1> no, the other way around
13:30:59 <sech1> a block doesn't always include everything from txpool
13:32:13 <hyc> I'm not seeing what purpose it serves to leave it in the txpool
13:32:19 <hyc> but ok, whatever
13:32:30 <sech1> no, you didn't understand
13:32:40 <sech1> transaction in a block are never left in mempool
13:32:52 <hyc> ok
13:32:55 <sech1> but not everything from mempool is taken
13:33:02 <sech1> if there are too many transactions
13:33:02 <hyc> ok, fine
13:33:19 <sech1> so cache can't be just cleared, it has to only remove old enough data
13:33:26 <hyc> so any cached txns that are in a block can have their hash removed from cache
13:33:38 <hyc> I didn't mean to expire the entire cache, only the relevant txns
13:34:16 <sech1> yes
13:34:33 <sech1> but I just went with simple logic of LRU cache (8192 entries)
13:34:39 <hyc> ok
13:34:45 <sech1> actually, it's not even LRU
13:34:55 <sech1> because entries are not moved to the front when they are used
13:35:02 <sech1> anyway, it works :D
13:35:07 <hyc> ;)
13:35:29 <hyc> yeah LRU is a pain anyway because of the movement. most people use CLOCK instead of LRU to avoid that
13:37:03 <sech1> in my tests, this function was called with the same input exactly two times, so ring buffer is enough
13:37:15 <sech1> very rarely 3 times when some alt blocks arrive
13:38:27 <hyc> cool
13:38:54 <hyc> but doesn't that mean as a cache its utilization rte is nearly zero?
13:38:58 <hyc> rate
13:39:16 <sech1> yes
13:39:33 <sech1> "cache" in a sense it gets answers to known inputs much quicker
14:50:56 <paalaa[m]> Sir if the new advanced user feature is converted from 24 words to 25 words, after I reset the ledger hardware wallet, can I access the same monero assets with just 24 words without +25 words in ledger hardware wallet? I don't mean passphrease in ledger hw. I mean the seed phrease (advanced users) for just the... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/a7051b7c791ffc809aefb2a2dacee6d8a1c0f233>)
14:56:13 <sech1> paalaa[m] ask in #monero-pools
15:05:04 <plowsof11> lol
15:05:34 <paalaa[m]> Plowsof sir
15:05:35 <paalaa[m]> Sir if the new advanced user feature is converted from 24 words to 25 words, after I reset the ledger hardware wallet, can I access the same monero assets with just 24 words without +25 words in ledger hardware wallet? I don't mean passphrease in ledger hw. I mean the seed phrease (advanced users) for just the... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/a7051b7c791ffc809aefb2a2dacee6d8a1c0f233>)
15:05:36 <paalaa[m]> A or B
15:05:52 <paalaa[m]> ?
15:05:52 <paalaa[m]> Write here
15:08:42 <paalaa[m]> Plowsof. I want f*ck u
15:10:19 <plowsof11> thanks but not in public im shy 
15:14:09 <hyc> so, if XMR price grew by 10x, then mining profit would increase, then more miners would come in, difficulty would raise, and eventually a new quilibrium would be reached
15:14:36 <hyc> at that point, your success rate * XMR value would still be the same as before
15:14:43 <hyc> but your success rate is 10x smaller than before
15:15:15 <hyc> so in order to actually have the same probability of success, you need to join up with other miners
15:30:55 <merope> Not sure if I'm missing any messages from the irc side, but yes - if we assume that the new equilibrium point will be at the same breakeven efficiency, then your fiat/time will be the same but your xmr/time rewards will be 10x smaller, and so will be your found blocks
15:38:09 <hyc> yeah that's all I was saying