08:49:11 <m-relay> <r​brunner7:monero.social> Did I miss something? moneroecosystem.org is now in the hands of some domain squatter and redirects to some shop page?
09:03:25 <plowsof> the maintainer of the non-monero-project repo archived it a while ago https://github.com/monero-ecosystem , i assume erciccione let the domain expire 
09:11:09 <m-relay> <r​brunner7:monero.social> Thanks for the info, plowsof. Seems that woodser's wallet API stuff was not archived along with the other things.
09:15:58 <m-relay> <3​21bob321:monero.social> monero-ecosystem.org is available
09:33:59 <m-relay> <o​frnxmr:monero.social> i'm surprised anybody ever agreed to allow their projects to live on fhe Monero-ecosystem github org. As if they couldnt have simply been mirrored or forked
09:34:25 <m-relay> <o​frnxmr:monero.social> Even the matrix space is dead / abandoned / broken
09:50:36 <m-relay> <s​yntheticbird:monero.social> meanwhile librejo alive.
09:50:46 <m-relay> <s​yntheticbird:monero.social> don't forget to backup your working branch on it
09:51:07 <m-relay> <s​yntheticbird:monero.social> there is plenty of storage
09:56:47 <m-relay> <r​brunner7:monero.social> Nice, but of course not for eternity either. If whoever maintains the domain and the server for that throws in the towel in anger a few years in the future they same think may happen ... just a fact of life.
10:30:45 <m-relay> <o​frnxmr:monero.social> wen M$ going to throw in the towel
10:35:05 <m-relay> <k​ewbit:matrix.org> What about moneroecosystem.com
10:37:01 <m-relay> <o​frnxmr:monero.social> Is it possible to use rx fast mode to validate blocks? Would it increase sync time today?
10:37:06 <m-relay> <o​frnxmr:monero.social> Decrease*
10:39:38 <m-relay> <s​yntheticbird:monero.social> rx?
10:40:46 <m-relay> <o​frnxmr:monero.social> Randomx
10:41:51 <m-relay> <o​frnxmr:monero.social> > Fast Mode requires 2GB of shared memory but has 4x-6x the performance of Light Mode which only requires 256MB of RAM. Fast mode is intended for dedicated miners. Light mode is designed to allow fullnodes to validate blocks without requiring the 2+GB of RAM
10:43:32 <m-relay> <o​frnxmr:monero.social> Validating blocks is pretty slow. I assume we'd have much better sync performance if we allowed fast mode by default, with opt in light mode. 2gb ram isnt much these days
10:45:52 <m-relay> <o​frnxmr:monero.social> Fast validation is more important than supporting running node on your smart toaster imo. We've seen a lot of issues on stressnet that are (probably or partly) due to slow-to-verify large blocks.
11:13:53 <m-relay> <s​yntheticbird:monero.social> cc boog900
11:31:36 <m-relay> <b​oog900:monero.social> There is a flag for that IIRC so you could test it
11:34:24 <m-relay> <b​oog900:monero.social> monerod and cuprate will both cache 2 VMs as well
11:44:57 <tobtoht_> kewbit: prefer .org for open-source projects https://en.wikipedia.org/wiki/.org
11:45:40 <m-relay> <k​ewbit:matrix.org> Yeah it has that stigma
13:24:04 <m-relay> <o​frnxmr:monero.social> Do you know the flag?
13:24:18 <m-relay> <o​frnxmr:monero.social> I dont see any ref to randomx
13:24:47 <m-relay> <o​frnxmr:monero.social> --fast-block-sync is for checkpoints, not rx
13:37:27 <m-relay> <b​oog900:monero.social> ah it's an environment variable: https://github.com/monero-project/monero/blob/a1dc85c5373a30f14aaf7dcfdd95f5a7375d3623/src/crypto/rx-slow-hash.c#L207
13:38:42 <m-relay> <b​oog900:monero.social> and the second cached VM will only cache the RX cache not the full dataset even if this is enabled
13:44:15 <m-relay> <o​frnxmr:monero.social> So shouldnt we just enable full rx?
13:45:42 <m-relay> <s​yntheticbird:monero.social> Isn't fast-sync just avoiding randomX verification?
13:46:08 <m-relay> <o​frnxmr:monero.social> Yes
13:46:16 <m-relay> <o​frnxmr:monero.social> And no
13:46:26 <m-relay> <s​yntheticbird:monero.social> No, for the latest blocks for sure
13:46:46 <m-relay> <o​frnxmr:monero.social> its avoiding slow mode
13:47:26 <m-relay> <o​frnxmr:monero.social> Chdckpoints are uses til latest release hardcoded heights, so majority of BC isnt actually verified locally
13:48:02 <m-relay> <o​frnxmr:monero.social> After checkpoints (or with --fast-block-sync=0), it verifies with light/slow mode
13:48:25 <m-relay> <s​yntheticbird:monero.social> That was my understanding as well, and since it represent only the a minority of the chain, I don't see a reason to enable full rx in fast-sync.
13:48:39 <m-relay> <s​yntheticbird:monero.social> That was my understanding as well, and since it represent only the a minority of the chain, I don't see a reason to enable full rx in fast-sync, by default.
13:49:06 <m-relay> <o​frnxmr:monero.social> Im assuming you dont run a stressnet node 😡
13:49:25 <m-relay> <s​yntheticbird:monero.social> I don't like stress indeed.
13:49:29 <m-relay> <o​frnxmr:monero.social> Syncing blocks normally is a painfully long experience
13:49:43 <m-relay> <o​frnxmr:monero.social> Syncing 7gb testnet takes like 20hrs
13:49:46 <m-relay> <s​yntheticbird:monero.social> but only because you don't have checkpoints for the stressnet
13:49:50 <m-relay> <o​frnxmr:monero.social> Its not scalable
13:50:08 <m-relay> <o​frnxmr:monero.social> Nodes reorg and take a long time to verify blocks
13:50:34 <m-relay> <o​frnxmr:monero.social> No, its because we have big blocks with 5000 tx in them
13:50:50 <m-relay> <s​yntheticbird:monero.social> If we take post-RCT timing (and enormous tx volume), this is reasonable with monerod syncing in full-sync.
13:51:18 <m-relay> <s​yntheticbird:monero.social> anyway my point is enabling full RX by default wouldn't make sense for fast-sync but for full-sync it does.
13:51:24 <m-relay> <o​frnxmr:monero.social> chdckpoints arent a solution. They speed up initial sync. They dont so anything for syncing a 7mb block
13:51:49 <m-relay> <o​frnxmr:monero.social> "full sync" is literally "running a node"
13:51:54 <m-relay> <o​frnxmr:monero.social> It shouldnt take 30sec to sync a block
13:52:01 <m-relay> <s​yntheticbird:monero.social> bro you understand me full-sync = no-fast-sync
13:52:19 <m-relay> <o​frnxmr:monero.social> Fast sync is a hack so ppl dont see how long it takes to verify
13:52:37 <m-relay> <o​frnxmr:monero.social> Yes, and it also means "the next block"
13:53:06 <m-relay> <o​frnxmr:monero.social> If the next block it 5mb, it takes like 30secs to sync. (i dont remember exact time)
13:53:50 <m-relay> <o​frnxmr:monero.social> Thats _way_ to long to propagate without being reorged
13:53:51 <m-relay> <b​oog900:monero.social> I wouldn't think enabling RX fast mode would actually help much here
13:54:21 <m-relay> <o​frnxmr:monero.social> that sucks.
13:54:54 <m-relay> <o​frnxmr:monero.social> I assumed (blindly) that it would be a similar 4-6x speedup
13:55:45 <m-relay> <b​oog900:monero.social> It would be a 4-6x speed up of RX but if RX only takes up 1% of the time to verify it wouldn't change much
14:07:55 <m-relay> <o​frnxmr:monero.social> How do we know the % is 1 and not 99?
14:08:27 <m-relay> <o​frnxmr:monero.social> What other ops are taking up the time?
14:10:46 <m-relay> <b​oog900:monero.social> I don't, it might make a difference on mainnet, however the cost of RX should be the same no matter the tx count
14:11:56 <m-relay> <b​oog900:monero.social> So it makes me think something else is taking up the time on stressnet
14:14:45 <m-relay> <o​frnxmr:monero.social> there shouldnt be any diff between networks at chain tip aside from block size and tx pool
14:16:56 <m-relay> <b​oog900:monero.social> exactly so the fact we don't take 30s to sync a block on mainnet makes me think RX isn't the issue here. However using RX full mem could still reduce block verification by on non trivial amount compared to normal mainnet time.
14:18:15 <m-relay> <o​frnxmr:monero.social> Mainnet blocks are 300kb vs 5mb on stressnet .. .. ..
14:18:37 <m-relay> <o​frnxmr:monero.social> Stressnet runs fine with 300kb blocks too
14:19:26 <m-relay> <o​frnxmr:monero.social> (were not at 5mb right now, but verification time seemingly grows with block size)
14:19:51 <m-relay> <b​oog900:monero.social> I know, all I am saying is this means RX full mem won't help
14:22:01 <m-relay> <o​frnxmr:monero.social> The more tx youre verifying, the longer it takes. Maybe its not rx, but you see the same slowdoen when popping blocks with a full tx pool
14:22:20 <m-relay> <o​frnxmr:monero.social> same slowdown when starting up the node with a large txpool
14:22:37 <m-relay> <o​frnxmr:monero.social> Which leads me to believe that # of tx definitely does matter
14:23:03 <m-relay> <o​frnxmr:monero.social> We can skip verification, which makes things near instant, so its not an io issue
14:31:02 <m-relay> <r​ucknium:monero.social> ofrnxmr: AFAIK. It's tx verification time. See my Table 1 on page 6: https://github.com/Rucknium/misc-research/blob/main/Monero-Black-Marble-Flood/pdf/monero-black-marble-optimal-fee-ring-size.pdf
14:31:53 <m-relay> <r​ucknium:monero.social> With ring size 16, block size 443KB, it takes 2.69 seconds to verify all txs in the block.
14:33:01 <m-relay> <r​ucknium:monero.social> See Appendix A for how those estimates were obtained.
14:34:20 <m-relay> <b​oog900:monero.social> I said for the cost of RX ... the number of txs defiantly matters for verification time