05:33:31 <normie63[m]> what the best way for a non dev IT person to contribute?  basically just run a full node?
05:34:30 <normie63[m]> if i wanted to pursue a dev skill path, where should I start if all I know is server hardware, windows and linux?
05:51:38 <ofrnxmr[m]> #monero-community-dev:monero.social 
05:51:38 <ofrnxmr[m]> This channel is for core development 
05:51:47 <ofrnxmr[m]> Hacking, c++ etc
05:52:50 <ofrnxmr[m]> #monero-dev:monero.social  is for core dev, hacking etc.
05:52:50 <ofrnxmr[m]> #monero-community-dev:monero.social is for lower level stuff
05:53:39 <normie63[m]> ok sorry
06:04:02 <ghostway[m]> > <@jeffro256:monero.social> > Another question, with ristretto points. Why are prime order groups harder to implement algorithms for?
06:04:02 <ghostway[m]> > 
06:04:02 <ghostway[m]> > They both have different challenges. When the number of possible elliptic curve points is not prime (e.g. Curve25519), you have to constantly worry about sanitizing curve points that are not in the correct subgroup, hence the existence of Ristretto. When you do not use prime subgroups (e.g. secp256k1 in BTC) you have to worry more about  Pohlig–Hellman algorithm attacks
06:04:02 <ghostway[m]> But why order h*l instead of l/q attractive?
06:08:27 <ghostway[m]> * But why is order h*l
14:48:40 <jeffro256[m]> Well the order of the subgroup we use is actually l, not h*l. h*l is the total number of points on E(Fq). Also, we cannot use q as the order since q is the size of the underlying integer field. 
14:49:13 <jeffro256[m]> AKA the base generator for curve25519 resides in a subgroup with prime order l
14:50:04 <ghostway[m]> jeffro256[m]: Ive read some time ago that ristretto expands the subgroup to use h*l
14:50:14 <ghostway[m]> but I don't know the correctness of that
14:57:46 <jeffro256[m]> I don't think so... If anything, some libraries even use scalars mod l instead of X, Y over mod q
14:58:31 <jeffro256[m]> They don't allow users to convert direct from an X value to a point (besides the base point), they have to use scalarmult against G
14:59:05 <jeffro256[m]> I would ask dangerousfreedom... They know better 
15:00:01 <jeffro256[m]> > They don't allow users to convert direct from an X value to a point
15:00:10 <jeffro256[m]> That doesn't apply when using DH in X25519
16:01:20 <ghostway[m]> <jeffro256[m]> "I don't think so... If anything,..." <- yea. I think sodium does
16:01:44 <ghostway[m]> (they have wrote the zig implementation of ed25519 in its standard library, which I explored some time ago)
18:18:04 <xfedex[m]> Hello. I have got a question about Monero Daemon RPC.... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/966e6cd924940f3003714cac3fc8c324ef0e28f8>)
18:36:39 <sech1> yes, next_seed_hash is just for reference
21:05:47 <selsta> .merges
21:05:47 -xmr-pr- 8720 8721 8736 8737 8738
21:11:09 <selsta> if someone runs a stagenet or testnet node please update to release-v0.18, would be great if we had some testers before we put out the release
21:11:24 <selsta> (or also mainnet)
21:12:52 <selsta> the dandelion++ code had changes, there's now a ringct cache and the monero side randomx code had a rewrite, so testing mining and sending transactions would be great
21:17:33 <plowsof11> all of the recent testnet spam during p2pool testing was broadcast from 2 nodes / wallet-rpc running release (both mainnet nodes currently have ~2MB/s traffic also and stable). The more testers the better! 
21:18:46 <selsta> my nodes have also been running release-v0.18 and so far everything good
22:07:15 <dangerousfreedom> <ghostway[m]> "but I don't know the correctness..." <- It is not expanding to use h*l points. It is remapping to l to avoid the overhead of multiplying by the cofactor, cleaning the scalar or other things.
22:36:50 <monerobull[m]> selsta: someone on Reddit has a problem with this https://github.com/monero-project/monero/issues/7708
22:37:04 <monerobull[m]> https://www.reddit.com/r/Monero/comments/10y6i7x/untransferable_xmr
22:38:01 <selsta> monerobull[m]: they have to add disable_noise
22:38:38 <selsta> `--proxy tor,127.0.0.1:9050,disable_noise`
22:38:40 <monerobull[m]> I'll tell them 
22:39:52 <monerobull[m]> What's the cause here (for dummies)?
22:40:02 <monerobull[m]> And how does that flag fix it
22:40:58 <monerobull[m]> Ah i see
22:41:09 <monerobull[m]> White-noise feature 
22:41:10 <selsta> the daemon constantly sends noise and in-between the noise it would send the transaction, in this case the transaction is simply to large and the node would switch to a different node before it's fully transmitted
22:41:11 <selsta> yep
22:41:19 <selsta> too*
22:41:32 <monerobull[m]> selsta: Woah, something about monero i didn't know
22:42:12 <monerobull[m]> Thanks!
23:39:41 <selsta> .merge+ 8739
23:39:41 <xmr-pr> Added