06:36:48 <m-relay> <b​lurt4949:matrix.org> Not sure if this is the right place to ask, but are there any known limitations on CLSAG ringsizes? I'm on a private testnet and aiming for ringsize = 2^20 (~1 million). I've successfully done 2^15, with 2 inputs even, but somewhere between there and 2^16 I get seemingly random errors such as "Error: internal error: Daemon response did not include the requested real output", and "<clipped message>
06:36:49 <m-relay> <b​lurt4949:matrix.org> Error: failed to get output: possibly lost connection to daemon". I don't know exactly where the limit is, but 50000 also seems to fail. Using the CLI wallet.
06:40:02 <moneromooo> Try increasing timeouts to silly high values, and running with plenty of RAM.
06:42:49 <moneromooo> Technically you can't use close to the amount of outputs available because the wallet asks for... 3x maybe... what it needs, so it can discard what can't be used and still have enough. But there's no inherent limit anywhere near 50k.
06:43:50 <moneromooo> However, you may run into the max tx size, which is basically half the max blck size (not consensus, consensus only limits to block size).
06:52:29 <m-relay> <b​lurt4949:matrix.org> I have the timeout set to 3 hours, and RPC content length limits, max block size limits, etc set to very high values. However, I do only have about 70000 outputs on in the network, so I'll try to ~4x that tomorrow. Thank you :)
06:52:59 <m-relay> <b​lurt4949:matrix.org> Might as well bump up the timeout more just to be safe, too.
07:00:47 <moneromooo> Look for "size_t base_requested_outputs_count = (size_t)((fake_outputs_count + 1) * 1.5 + 1);" in wallet2.cpp, it's 1.5x, not 3x. Just change it to be 1.0 and + 61 (there'll be 60 locked coinbases that aren't usable, plus one because easier than to think).
08:13:23 <rbrunner> blurt4949: Just curious, what's the motivation behind this finding of limits? Is there a use case for ringsizes of 10,000 members or so?
09:01:04 <m-relay> <s​omeoneelse495495:matrix.org> Be aware monero channels are broken on Matrix. Messages from monero.social accounts take hours/days to come on matrix.org.
09:01:04 <m-relay> <s​omeoneelse495495:matrix.org> Aside, you shouldalso  ask that question on  Monero Research Lounge
11:01:48 <rthorsen> Recently compiled 0.18.3.3 (migrated from 0.18.1.0 that was reasonably stable before mempool floods) and started to have "std::bad_alloc" exceptions all day along in monerod running on Debian 11 (without non-free and contrib repos)
11:02:05 <rthorsen> I was able to capture a specific pattern that sometimes repeats every few minutes: https://paste.debian.net/1313208/
11:02:56 <rthorsen> any idea on what it might be?
11:05:01 <rthorsen> monerod runs without any startup params or custom configuration
11:12:17 <rthorsen> it also affects RPC reachability and results into random 'no connection to daemon' on the wallet RPC, exactly during interval when this exception happens +-30s
11:22:29 <rthorsen> no abnormalities in RAM usage
11:22:40 <rthorsen> the hw specs are 16 cpu threads / 32 GB RAM / NVMe disk 
12:27:42 <moneromooo> Ideally, the stack trace would list the calls, but it broke long ago and nobody put the work in to fix it, me included. What you can do instead is attach with gdb (gdb PID), then:
12:27:51 <moneromooo> catch throw
12:27:54 <moneromooo> cont
12:28:26 <moneromooo> Then, type "cont" until the stack trace is the one you expect (bt to see).
12:54:05 <moneromooo> Seeing the place it seems to happen (based on the timestamps and the "block_batches" log just prior to it), it's probably randomx trying to allocate huge pages and failing.
12:54:35 <moneromooo> That should not cause RPC issues though, so maybe not...
14:05:08 <m-relay> <d​etherminal:matrix.org> Is PoW change planned for Seraphis or etc.?
14:06:51 <rbrunner> No.
14:07:25 <rbrunner> There is an update for RandomX in the works that adjusts a few things. Technically, this is a PoW change and needs a hardfork to introduce.
15:20:35 <rbrunner> Seems to me we are in danger to fail *again* to get rid of tx locks. This PR waits quite a while already and has 1 rewiew (from me):
15:20:36 <rbrunner> https://github.com/monero-project/monero/pull/9151
15:21:16 <rbrunner> (First attempt to get rid of this was 2020/2021)
15:23:31 <rbrunner> Diskussion in the MRL meeting and on GitHub was almost 2 months ago.
15:23:58 <rbrunner> Er, not GitHub, Reddit: https://old.reddit.com/r/Monero/comments/1amomjj/timelocks_let_us_finally_retire_a_rarely_used_and/
15:42:02 <m-relay> <x​fedex:matrix.org> no, randomx/v2 is planned, to be decided, but it's not really related to / required by seraphis
19:22:28 <m-relay> <1​23bob123:matrix.org> https://libera.monerologs.net/
19:22:28 <m-relay> <1​23bob123:matrix.org> easier to see responses
22:27:11 <m-relay> <n​obfg9000:matrix.org> wait, monero has timelocks?
22:27:16 <m-relay> <n​obfg9000:matrix.org> interesting
22:27:41 <m-relay> <n​obfg9000:matrix.org> couldn't you do this to implement subscriptions in a passive-ish way?
22:30:11 <m-relay> <n​obfg9000:matrix.org> like if I want to "subscribe" to some service from you for 0.05 XMR/month for a year, I could just draft and sign 12 of 0.05 XMR transactions with timelocks and give them to you. That way I don't need to have a running daemon like https://github.com/lukeprofits/Monero_Payment_Request_Standard and If I want to cancel the subscription midway I just churn the coins that would otherwi<clipped message>
22:30:11 <m-relay> <n​obfg9000:matrix.org> se have been sent.
22:40:21 <m-relay> <n​obfg9000:matrix.org> damn its already documented on github, i thought that was an original idea