16:41:51 <Guest56> hi in \monero\external\supercop\crypto-sign\ed25519 there are two implementations:
16:41:51 <Guest56> - amd64-51-30k
16:41:52 <Guest56> - amd64-64-24k
16:41:52 <Guest56> What is the difference?
16:42:25 <Guest56> sech1 maybe you know?
16:45:09 <m-relay> <v​tnerd:monero.social> One uses 51bit limbs with a 30k precomputation table, and the other uses 64 bit limbs with a 24k precomputation table. They have different performance characteristics on different cpus. The larger table thrashes the cache more, but has less less overflow scenarios on 64 bit integers
16:45:53 <m-relay> <v​tnerd:monero.social> There's a utility to benchmark the two to determine which is best for your cpu
16:47:16 <Guest56> Are both implementations for linux only?
16:47:53 <Guest56> Or maybe only for AMD cpu's?
16:52:20 <m-relay> <v​tnerd:monero.social> They are for x86-64 only, so amd and Intel. It is currently limited to system V calling convention due to assembly files. So it could work on Linux, bsd, and macos - let me check what systems it is currently enabled for though
16:55:54 <m-relay> <v​tnerd:monero.social> They should be enabled for bsd and macos as well. Only windows builds should be omitted right noe
16:56:02 <m-relay> <v​tnerd:monero.social> *now
16:56:55 <Guest56> There is also an implementation in src\crypto\crypto.cpp which implementation is it?
16:57:04 <Guest56> 64bit limbs right?
16:58:16 <m-relay> <v​tnerd:monero.social> No that is basically "ref10" which has  32bit limbs and 32 bit integers
16:58:57 <Guest56> hmm
16:59:37 <m-relay> <v​tnerd:monero.social> I'm planned (at some point) a donna64 investigation for use in LWS scanning - it should see speed improvements on all 64 but processors and oses
16:59:44 <Guest56> Which implementation would be faster if the CPU supports it?
16:59:45 <Guest56> 64bit limbs?
16:59:49 <m-relay> <v​tnerd:monero.social> *bit
17:01:11 <m-relay> <v​tnerd:monero.social> Yes. You can test the speed difference with the benchmark utility - it provides comparisons against each 64 bit implementation and the basic ref10/32bit implementation
17:01:33 <Guest56> Where do I find the benchmark utility?
17:01:39 <m-relay> <v​tnerd:monero.social> I forget the speed difference, let me see if it's in the notes somewhere
17:01:46 <Guest56> Yes please
17:02:55 <Guest56> Both 51limbs and 64bit limbs should be faster than the 32bit limb implementation as long as the CPU supports 64bit integers, I assume.
17:07:04 <Guest56> vtnerd still there?
17:07:18 <m-relay> <v​tnerd:monero.social> Yes. The benchmark utility is built with the tests - or `make monero-wallet-crypto-bench`. Look in the `tests/` folder of the cmake output directory for the executable with the same name.
17:09:50 <m-relay> <v​tnerd:monero.social> https://github.com/monero-project/monero/pull/6337
17:09:54 <Guest56> I currently have some issues with vscode cmake. Can you show me your benchmark results?
17:10:21 <Guest56> Ah, it looks like there is a benchmark
17:11:27 <m-relay> <v​tnerd:monero.social> Just did, look in the above link for results with a Ryzen 3900x. It's ~146% slower to use the 32bit code. The real scan time was improved by 28%
17:12:24 <m-relay> <v​tnerd:monero.social> We didn't see optimal gains because of how the blocks are fetched, something the new scanner for fcmp++ should improve further
17:13:39 <Guest56> I see, thanks
17:14:50 <Guest56> where can I find the new scanner for fcmp++?
17:18:20 <m-relay> <v​tnerd:monero.social> Uh, it's really not available yet. I guess you could look in jbermans repo
17:19:50 <m-relay> <v​tnerd:monero.social> The latest is here https://github.com/j-berman/monero
17:20:55 <m-relay> <v​tnerd:monero.social> There's also https://github.com/seraphis-migration/monero
17:21:28 <m-relay> <v​tnerd:monero.social> I'm not sure of the status of either repo tbh, jberman would probably be the best contact for that
17:23:54 <Guest56> where are the main changes?
17:27:32 <m-relay> <v​tnerd:monero.social> His irc handle is the same
17:34:59 <m-relay> <v​tnerd:monero.social> You'd have to ask him directly, I'm not sure which of his branches is the best. The earlier ones with `seraphis` in the name wouldve been the related ones, but he may have abandoned that for something involving `fcmp` in the name
17:35:32 <Guest56> ahh ok
17:36:29 <m-relay> <v​tnerd:monero.social> https://github.com/j-berman/monero/tree/seraphis_lib_scanner_blockchain_scanner
17:37:16 <Guest56> Who exactly is Justin Berman?
17:37:38 <m-relay> <v​tnerd:monero.social> That branch is probably a good start until he responds. There's several folders labeled seraphis which should support "legacy" and seraphis scanning. The seraphis branches have gone stale as development shifted to something called fcmp
17:38:03 <Guest56> hmm
17:40:19 <m-relay> <v​tnerd:monero.social> A dev that is CCS funded to work on monero
17:40:20 <m-relay> <v​tnerd:monero.social>  More specifically his work is now focused on integrating fcmp++ so that monero no longer uses ring signatures in favor of including all outstanding outputs as candidates for spending (similar to zcash shielded pools)
17:40:53 <Guest56> I see
17:41:16 <Guest56> What is the the issue with RingSIG?
17:42:33 <Guest56> Also is zcash not beeing spammed?
17:42:45 <Guest56> I wonder why
17:49:57 <Guest56> there is also qhasm stuff in external\supercop\ why another implementation?
18:03:03 <m-relay> <v​tnerd:monero.social> qhasm stuff? You mean in `src/amd64`? I tried to minimize changes to the supercop upstream directories, and put some new assembly files in that folder. And the assembly files are mostly copy-paste anyway
18:06:30 <m-relay> <v​tnerd:monero.social> Ring signatures have a smaller anonymity set that can theoretically be attacked if someone dominates the txes in my every block (i.e. they create lots of dummy transactions). FCMP is harder to defeat since the spend can from _any_ prior output/tx
18:28:59 <m-relay> <j​berman:monero.social> For fcmp++'s, we're implementing a merkle tree for all outputs in the chain. Full-wallet scanners need to keep track of every received output's complete path in the merkle tree (scanning isn't implemented yet)
18:29:20 <m-relay> <j​berman:monero.social> We've been discussing an optimized approach in the no-wallet-left-behind channel. @jeffro256 proposed full wallets keep a pruned tree saved
18:29:50 <m-relay> <j​berman:monero.social> I believe this can work by keeping all members of the right-most path in the tree for each block saved, up to some reorg depth
18:30:26 <m-relay> <j​berman:monero.social> I wrote up this description (slightly modified) and sent the description to @dangerousfreedom who's aiming to tackle this (it doesn't account for reorg handling as written): https://paste.debian.net/1324876/
18:53:00 <Guest56> nice jberman
18:55:09 <Guest56> jberman where can I find the implementation for fcmp++ in your repository?
18:55:32 <m-relay> <j​berman:monero.social> the fcmp++ branch
18:56:12 <Guest56> in here right?
18:56:12 <Guest56> https://github.com/j-berman/monero/tree/seraphis_lib_scanner_blockchain_scanner
18:57:11 <m-relay> <j​berman:monero.social> no that branch doesn't have any fcmp related stuff implemented
18:57:28 <m-relay> <j​berman:monero.social> https://github.com/j-berman/monero/tree/fcmp%2B%2B
18:58:14 <Guest56> can you ahhhh
18:58:15 <m-relay> <j​berman:monero.social> this branch^ I just linked includes daemon-side changes to sync the merkle tree, no scanning or wallet-side changes implemented in there
18:58:18 <Guest56> now I see
18:58:21 <Guest56> in fcmp
18:59:29 <Guest56> jberman do you have a youtube channel by any chance explaining these implementations?
18:59:33 <m-relay> <j​berman:monero.social> however as noted in that paste I linked above, I think some functions I wrote there could be reused for wallet sync too, when it's implemented
18:59:34 <Guest56> or docs?
19:00:20 <m-relay> <j​berman:monero.social> @kayabaNerve wrote a good specification of fcmp++'s here: https://github.com/kayabaNerve/fcmp-ringct/blob/develop/fcmp%2B%2B.pdf
19:00:58 <m-relay> <j​berman:monero.social> section 6 includes integration-related changes. the scanner stuff is a little out of date since the discussions on the optimized approach are relatively fresh
19:01:32 <m-relay> <j​berman:monero.social> I intend to write docs explaining my implementation too soon
19:02:19 <Guest56> jberman do you have twitter or where do we get notifications about your work?
19:02:35 <Guest56> *or X
19:04:48 <m-relay> <j​berman:monero.social> we have meetings in the no-wallet-left-behind channel every Monday at 18:00 UTC, and meetings in the monero-research-lab every Wednesday at 17:00 UTC
19:05:09 <m-relay> <j​berman:monero.social> meeting logs are posted here: https://github.com/monero-project/meta/issues/1045
19:05:17 <m-relay> <j​berman:monero.social> I'm not really active on twitter
19:09:03 <Guest56> jberman - noted, thanks
19:47:04 <Guest56> which CPU's work better with 64-64-24k? and which work better with 64-51-30k?
19:47:32 <Guest56> which rule determines that?
20:14:30 <m-relay> <v​tnerd:monero.social> https://bench.cr.yp.to/impl-sign/ed25519.html
20:15:00 <m-relay> <v​tnerd:monero.social> Typically the 64-51-30k variant is just slightly faster on some Intel cpus
20:15:46 <m-relay> <v​tnerd:monero.social> As you can see it's never by much
20:59:04 <Guest56> thanks vtnerd
21:04:59 <Guest56> so if I interpret that graph correctly the 64-64-24k variant is the best algorithm available
21:06:01 <Guest56> because it has the lowest trycycles on most cpus
21:07:51 <Guest56> (using it on a CPU in which 64-51-30k would be better would just increase the speed slightly over using 64-64-24k on these CPU's)
21:08:55 <Guest56> so I also understand from this that the 64-64-24k algorithm would also work on these CPU's
21:09:05 <Guest56> (almost as well)
21:19:22 <m-relay> <v​tnerd:monero.social> Yes, the monero wallet and the supercop cmake code default to 64-64-24k for this reason
21:21:51 <Guest56> great! I am really new to this source code, so I am learning this just now
23:53:35 <m-relay> <r​edhawk18:matrix.org> Hey is there a protocol on how to connect to a pool? Currently I'm trying to test a web socket connection but before I can even send the json needed to login the pool closes the socket. Does anyone know why this happens? 
23:53:36 <m-relay> <r​edhawk18:matrix.org> I read here that everything is done with a tcp socket which is what a web socket should be so I'm confused.
23:53:38 <m-relay> <r​edhawk18:matrix.org> https://monero.stackexchange.com/questions/10867/what-exactly-do-miners-communicate-with-a-pool/10869#10869
23:54:57 <m-relay> <r​edhawk18:matrix.org> I visited the pool channel and noticed that it wasn't really the type of discussion that would be needed to ask highly technical questions.