03:43:25 <jeffro256[m]> .merges
03:43:25 -xmr-pr- 8736
11:05:36 <ypavtv97lx[m]> Anyone knows what selsta meant by "RandomX refactor" ? https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/372
11:06:09 <selsta> ypavtv97lx[m]: yes, will link it
11:06:32 <ypavtv97lx[m]> thanks!
11:06:45 <selsta> 8677/8678
11:07:04 <selsta> the RandomX integration in monero not RandomX itself
11:07:13 <ypavtv97lx[m]> oh kk
12:44:24 <ghostway[m]> Question, when I send someone some monero, I can't know if they spent it because I can't calculate the key image, but I can see if they were used with a ring signature right?
12:44:45 <ghostway[m]> Because the one time key is still included in the ring
12:45:17 <ghostway[m]> * the ring (possibly not by them)
12:58:15 <UkoeHB> ghostway[m]: yes
12:58:15 <dEBRUYNE> ghostway[m]: Yes
12:59:57 <ghostway[m]> Cool
16:49:32 <someoneelse49549> Could someone explain to me the purpose of the get_blocks_from() function in blockchainDB. I don't get how flexible this function is nor why it isn't even use, except for one assert?
16:53:27 <moneromooo> faster fetching of consecutive txes
17:02:09 <someoneelse49549> i understand no
17:02:10 <someoneelse49549>  * i understand now
20:23:20 <selsta> .merge+ 8737 8738
20:23:20 <xmr-pr> Added
20:39:37 <sgp[m]> Hey, weird question/observation. I'm using an alpha test build of Cake Wallet, and I was able to observe the following:
20:39:37 <sgp[m]> I asked ofrnxmr to send me XMR with a 20 block lock. He did in tx `a8c3c7828eac61bfc228d894378e8417330e181b3a15a88770ccf0d6ede6b0f2`
20:39:37 <sgp[m]> I waited 10 blocks, then I attempted to spend the funds before the 20 block lock time expired. I appear to have been able to do so in tx `d777250fcba14ad70fb4b656c2a5b584f6926b5ce90051b405794c7f56532487`
20:39:37 <sgp[m]> Do you have any idea how this is possible? The wallet was fresh and is only associated with those 2 transactions.
20:41:38 <sgp[m]> https://monero.com/payment/d777250fcba14ad70fb4b656c2a5b584f6926b5ce90051b405794c7f56532487/8Bb9z1bbiKmD9XekA7uESXRzunasN1ndej6FUm1bRFEtSPFqVWvHPtD2LDwhARikcxNkCsmaBcGGF2VSeFWhMe57FGXNaZP/f2c41bee4bb598f340ebaf648a212f01c9114f02c2e25d714499646b71f4e105/
20:43:59 <sgp[m]> ahhhh, 20 is the absolutely block height isn't it. So it's spendable after block height 20, which it's well past then ofc
20:44:05 <selsta>  "unlock_time": 0, 
20:44:12 <selsta> it isn't locked
20:44:23 <sgp[m]> s/absolutely/absolute/, s//`/, s/,/`,/
20:44:47 <Rucknium[m]> sgp: Correct usage: https://thecharlatan.ch/Monero-Unlock-Time-Privacy/
20:44:47 <sgp[m]> the first transaction was unlock_time:20
20:44:54 <sgp[m]> okay so 20 blockheight not additional block 
20:44:58 <sgp[m]> s/block/blocks/
20:45:09 <sgp[m]> sorry, I knew this, just got caught up in the moment while testing
20:45:54 <selsta> I checked the wrong txid but what you said should explain it
20:46:17 <sgp[m]> thanks, all solved now
20:50:19 <ghostway[m]> Another question, with ristretto points. Why are prime order groups harder to implement algorithms for?
20:53:41 <ofrnxmr[m]> 🫡 ofrnxmr didnt know how to lock funds 
20:53:41 <ofrnxmr[m]> #RTFM
20:55:01 <ofrnxmr[m]> To be fair, I was mislead
20:55:01 <ofrnxmr[m]> ```
20:55:01 <ofrnxmr[m]> unlock_time - unsigned int; Number of blocks before the monero can be spent (0 to not add a lock).
20:55:01 <ofrnxmr[m]> ```
21:05:23 <smathy[m]> That can still mean an absolute block.
21:05:29 <smathy[m]> (not like it said "number of blocks from now"...)
21:12:51 <ofrnxmr[m]> Yeah, I read it as "number if blocks before the Monero can be spent", ignored the unsigned int part.
21:12:51 <ofrnxmr[m]> An easier way to describe it would be "Height to unlock" 
21:19:43 <selsta> .merge+ 8720 8721
21:19:43 <xmr-pr> Added
21:20:17 <selsta> if anyone runs a seed node please check https://github.com/monero-project/monero/pull/8720, I have removed the ones that are offline
21:20:38 <selsta> if the node can be brought back online I'll re-add the IP
21:24:34 <jeffro256[m]> > Another question, with ristretto points. Why are prime order groups harder to implement algorithms for?
21:24:35 <jeffro256[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