00:10:39 <drflashd[m]> does monero blockchain import tool support symlink, it seems not: file not found
01:19:27 <jeffro256[m]> > because p2pool can generate transactions with much more than 16 outputs
01:19:27 <jeffro256[m]> Isn't the number of outputs limited to 16, or is that only for non-coinbase transactions?
01:30:52 <UkoeHB> non-coinbase
01:31:11 <UkoeHB> the limit was imposed due to how bulletproofs are constructed
01:35:09 <UkoeHB> I got AES working with jamtis address tags, but... my test show it is 10x slower than blowfish for decrypting a single block (blowfish is a 64-bit block, AES is 128-bit, so it's 5x slower per bit).
01:57:19 <jeffro256[m]> > the limit was imposed due to how bulletproofs are constructed
01:58:17 <jeffro256[m]> Interesting, I always thought it was so that decoy flooding attacks were harder to pull off
02:14:44 <UkoeHB> Ok I tried tiny AES ( https://github.com/kokke/tiny-AES-c ) but only got ~20% faster. Looking at mbedtls and openssl but their code looks really annoying to extract... hmm
02:19:34 <jeffro256[m]> Is twofish on table or no?
02:19:48 <jeffro256[m]> Sorry if this discussion was already had
02:20:02 <jeffro256[m]> *on the
02:20:38 <jeffro256[m]> Or cha cha?
02:21:51 <jeffro256[m]> AES is definitely the most battle hardened
02:22:39 <UkoeHB> twofish is a possibility, the code just looks like a pita so I've been avoiding it lol
02:22:53 <UkoeHB> all this c makes my head hurt
02:25:09 <UkoeHB> (I found better code with a license that can actually maybe be used... pending)
02:26:12 <jeffro256[m]> > (I found better code with a license that can actually maybe be used... pending)
02:26:12 <jeffro256[m]> For twofish?
02:26:27 <jeffro256[m]> > all this c makes my head hurt
02:26:27 <jeffro256[m]> I really felt that 
02:29:42 <UkoeHB> yeah twofish
02:58:28 <UkoeHB> jeffro256[m]: whoo twofish is way faster than aes (and probably a lot of optimizations on the table in this code I found)
03:00:41 <jeffro256[m]> Yay! Twofish is a "newer" (1998) cipher but it has stood up pretty well so far 
03:00:57 <jeffro256[m]> Should blow AES out of the water in terms of performace. Also it's very tunable!
03:04:38 <jeffro256[m]> I don't think we have any twofish code in the code tree though
03:04:54 <jeffro256[m]> But didn't you mention that we didn't have AES encryption code anyways either?
03:05:05 <UkoeHB> we have oaes (open aes)
03:05:17 <UkoeHB> that's what I tested first, then tiny aes which was faster
03:06:07 <UkoeHB> I have already added blake2b, blowfish, siphash, tiny aes, and now twofish to my branch (most of those can be removed). Getting good at this lol
03:10:53 <jeffro256[m]> Is your branch on your GitHub (I can test out performace later if you'd like)
03:12:01 <jeffro256[m]> How much better was Twofish? I'm kind of surpised Twofish did so well since a lot of hardware has acceleration for  AES
03:12:41 <UkoeHB> well the aes I was using is just raw c
03:15:02 <UkoeHB> https://github.com/UkoeHB/monero/tree/seraphis_lib
03:15:03 <UkoeHB> the perf test I run: ./build/Darwin/seraphis_lib/release/tests/performance_tests/performance_tests --filter=\*test_remote_scanner_client_scan_sp\* --stats
03:15:03 <UkoeHB> implementation of the ciphers (check cipher context): https://github.com/UkoeHB/monero/blob/seraphis_lib/src/seraphis/jamtis_address_tag_utils.cpp
03:15:03 <UkoeHB> I'm not doing a direct performance test of the ciphers (that would probably be more robust).
03:24:28 <UkoeHB> jeffro256[m]: twofish was ~5x faster than my fastest run with tiny aes (using a 16-byte key)
03:32:18 <jeffro256[m]> Wow that's pretty good!
03:33:28 <jeffro256[m]> The real test would be to compare it against a heavy-hitter native library like OpenSSL's implementation
03:34:01 <jeffro256[m]> For reference, I compared the speed of our in-tree MD5 hash function to OpenSSL's on my machine and OpenSSL was 4x faster
03:35:52 <jeffro256[m]> I'll definittely take a look later. right now I'm trying to finish this homework before midnight lol
03:36:14 <UkoeHB> no worries and no rush :) it's pretty plug-and-play for this usecase
07:22:25 <monerobull[m]> Great job on the GUI, can confirm long close-times are fixed.
08:20:01 <sech1> UkoeHB AES can't be slower, CPUs have dedicated instructions for it. You probably tested software implementation
11:01:33 <moneromooo> jberman[m]: 8046, do you want the first commit removed then if it seldom applies ?
11:09:28 <selsta> this person keeps opening nonsense issues and then complains when I close them lol https://github.com/monero-project/monero/issues/8303
12:52:57 <monerobull[m]> <selsta> "this person keeps opening..." <- Tell them to go back to Bitcoin if they hate updates so much
13:02:25 <rbrunner> Any time you think things can't possibly get any crazier, something like this comes along.
13:07:18 <monerobull[m]> Watch 5 new coins getting created on the uncontested v18 :P
13:07:34 <monerobull[m]> s/getting/get/
16:15:28 <hyc> can we ban web-sharp from the repo please
16:19:23 <jeffro256[m]> -- Doesn't understand how to run tests
16:19:27 <jeffro256[m]> -- Wants a release rollback
16:19:53 <hyc> -- doesn't read carefully, even his own writing
16:20:26 <jeffro256[m]> -- Accuses selsta of a "51%" attack by *checks notes* tagging a new release
16:20:31 <hyc> dunno what a dumbshit like that is doing paying for a pro github acct
16:21:06 <jeffro256[m]> -- Doesn't understand make targets
16:21:17 <jeffro256[m]> -- Doubles down
16:21:32 <jeffro256[m]> -- Yet still wants to distribute their binaries as "official"
16:33:11 <w[m]> Im surprised he didnt ask to speak with the manager.. 
16:42:17 <jeffro256[m]> Does anyone here have any expereince with valgrind's massif tool?
16:48:33 <moneromooo> I've used it a few times. Got me to kill the ugly spike in a game when switching levels. A bit hard to see what's going on for sure though. There are a couple GUIs for its outputs.
16:48:57 <moneromooo> The GUIs are real helpful there, you can see the evolution of the main hogs with time.
16:49:10 <moneromooo> Much more helpful than for, say, perf.
17:19:10 <drflashd[m]> nice, i want sync/relay over clear&tor idgaf,... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/89003242462a921800a809cda94d1b2fd23fa3ab)
17:19:43 <drflashd[m]> i will not punch port holes, so only outgoing
17:19:52 <drflashd[m]> how?
17:22:53 <cryptogrampy[m]> > <@flashd:matrix.org> nice, i want sync/relay over clear&tor idgaf,... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/061e551057842d2e67d9471e9a00892357cca335)
17:24:44 <w[m]> Whoops yes jeffro, meet me over there
17:24:50 <jeffro256[m]> moneromooo Nice! I'm going to try to use to see what is taking up so much RAM with with monerod, but I keep getting invalid callstack errors when running with massif. Isn't there a callstack library that the monero code is using, and is it possible to turn if off?
17:25:17 <selsta> unwind?
17:25:22 <w[m]> * Whoops yes dr flash*****, meet me over there
17:27:34 <selsta> jeffro256[m]: https://github.com/monero-project/monero/blob/9a124f681119855949f6406ecd69c2ad91da9770/src/common/stack_trace.cpp
17:27:45 <selsta> do you mean that?
17:28:27 <moneromooo> Hmm. Not sure. I have a custom patch for stack trace, never got PR'd. Might help, but IIRC these things tend to stop in a huff very easily...
17:28:56 <moneromooo> If you look in my crash branch, git log and grep for "stack" and you'll find it.
17:29:04 <moneromooo> It uses boost's stack trace system IIRC.
17:29:46 <moneromooo> Make sure you build with -g, don't use -s at link time, -fno-omit-frame-pointer might help, though I think it's off at -O2 and below...
17:30:03 <moneromooo> -g should not be needed per se, but doesn't hurt.
17:31:47 * FenderQ compiled master 67e5ca9ad, and v0.17.3.2 ok on OpenBSD amd64
17:31:59 <FenderQ> I had to do a non -static build for the tag though
17:32:07 <FenderQ> so it would link with libunbound from packages
17:32:14 <FenderQ> catering to liberssl
17:32:25 <FenderQ> yet master has unbound removed afaik (submodule)
17:35:30 <FenderQ> libressl*
17:40:59 <moneromooo> (note that I dunno whether this patch would help, I'm not sure why boost and/or unwind and/or builtin give good traces or not)
18:51:41 <drflashd[m]> E exceptin in main! failed to init p2p server... why?
18:53:16 <drflashd[m]> --anonymous-inbound= is not eaten it seems but why
18:53:17 <drflashd[m]> how to get verbose logging
18:56:56 <drflashd[m]> * verbose logging (where is monerod.log file?)
18:58:31 <w[m]> Anonymous inbound have to set an unused port, not 18080
18:58:31 <w[m]> Use 18084
18:58:31 <w[m]> 18083 is used for p2pool
18:59:13 <w[m]> Log file should be in .bitmonero folder in home directory 
19:02:54 <drflashd[m]> w[m]: no more output comapred to console print = bad!
19:02:54 <w[m]> Hey, wrong chat room! 
19:02:54 <drflashd[m]> i use 18083 p2p only (no 18081 for wallet rpc for now)
19:03:04 <w[m]> This is -dev
19:29:03 <drflashd[m]> hey dev, why --tx-proxy= mandatory for p2pserver?
21:13:14 <jberman[m]> <moneromooo> "jberman: 8046, do you want the..." <- responded, didn't consider the case of reusing across attempts, approved as is