00:24:21 <ooo123ooo1234[m]> s/cencorship/censorship/
00:32:55 <elizabeth[m]> hey all, are there any companies/people recommended for audits? wondering if there's any gotos for Monero stuff 
00:36:34 <selsta> elizabeth[m]: you can look at the bulletproof and randomx audits
00:37:12 <selsta> https://github.com/hyc/RandomxAudits
00:40:06 <selsta> i think for bulletproofs quarkslab did the most extensive work https://blog.quarkslab.com/security-audit-of-monero-bulletproofs.html
01:20:17 <merope> ooo123ooo1234[m]: relevant xkcd: https://xkcd.com/1357/
01:24:30 <ooo123ooo1234[m]> endor00[m]: https://xkcd.com/2548/ also relevant
01:50:37 <elizabeth[m]> selsta: thanks!
02:20:07 <selsta> .merges
02:20:07 -xmr-pr- 8318 8324 8325 8326 8328 8330 8331
02:20:48 <selsta> luigi1111w: ^ and gui too please
03:59:36 <rolodondo34[m]> anybody here use the monerujo wallet?
07:15:25 <spirobel[m]> is it okay to make integrated addresses with subaddresses? the wallet-rpc tells me no: 
07:15:26 <spirobel[m]> {... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/d40c51a098fd5e9f434333c547d57c6b35fb7bdc)
07:16:42 <spirobel[m]> and also it seems like the payment id needs to be specified when I use the primary address 
07:16:43 <spirobel[m]> {... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/42ca1847dc054e7b7c8fbfd22c667c5e1c1e8652)
07:16:51 <spirobel[m]> even though the docs says it is optional
07:34:44 <moneromooo> No.
07:35:29 <spirobel[m]> moneromooo: why not? is there anything I can read to understand why this limitation exists? 
07:35:43 <moneromooo> Deemed too confusing.
07:36:01 <spirobel[m]> moneromooo: for the user or the implementor? 
07:36:24 <moneromooo> IIRC there's some discussion about this on the github PR for the patch that added subaddresses.
07:36:27 <moneromooo> The user.
07:37:49 <spirobel[m]> moneromooo: for me it is important. I want people to login to websites with their subaddresses  similar to how metamask does it. Then I want to create integrated addresses for these users so they can sell stuff in a non fiduciary way on my website.
09:32:42 <moneromooo> spirobel[m]: https://github.com/monero-project/monero/pull/8355
09:34:35 <moneromooo> Only the default background refresh uses the chunked method atm.
12:05:34 <spirobel[m]> <moneromooo> "spirobel: https://github.com/..." <- wow this is interesting! The refresh method is the method that will fetch new blocks and see if there was money for the wallet holder in the transactions, right? and because it would fetch lots of blocks at the same time it would get stuck in this loop and the rpc wouldnt be responsive until this loop got unstuck, right?
12:28:23 <moneromooo> Yes and yes.
12:29:23 <moneromooo> I expect wallet refresh to slow down, as this will preempt the overlap between processing blocks and fetching the next blocks.
12:30:11 <moneromooo> Maybe fetching fewer blocks at once, and/or making at least N loops, will mitigate if it proves too much.
12:30:27 <moneromooo> In any case, wallet concurrency is very basic now anyway.
12:45:27 <spirobel[m]> <moneromooo> "In any case, wallet concurrency..." <- I like that monero-javascript has webworkers, so it is essentially like a multi threaded program. 
14:48:07 <Elijah[m]> elizabeth: hey when you do find an auditor for the xmr-eth swap, could you make sure they talk about how they audited the contract verification part done by Bob? I was looking at the code yesterday and I couldn't wrap my head around the part where event is used and how the parsing of the deployed contract is done. My concern for the swap is that a bad actor can deploy a fraudulent contract with the same parameters/attributes but the body
14:48:08 <Elijah[m]> of the contract functions are rigged. Was this concern of mine already accounted for? 
14:48:34 <Elijah[m]> s/Was/Is/
15:05:27 <elizabeth[m]> <Elijah[m]> "elizabeth: hey when you do..." <- hey yeah for sure, I implemented a check for that which checks that the on-chain contract code matches the compiled bytecode, but the problem is it's kind of janky right now since the compiled code isn't exactly the same as what ends up on chain (there's extra instructions in the compiled code) the current check *should* work, but it's a bit too hard-coded for my liking since it checks that
15:05:28 <elizabeth[m]> specific parts of the bytecode match 
15:05:38 <elizabeth[m]> but definitely something really important 
16:43:56 <rbrunner> .merges
16:43:56 -xmr-pr- 8318 8324 8325 8326 8328 8330 8331
17:32:32 <sethforprivacy> Friendly reminder we have an open PR from Trezor that will need to be merged before binary release: https://github.com/monero-project/monero/pull/8299
17:37:12 <sethforprivacy> And we have a check-list to make sure we don't miss any important steps in the network upgrade: https://github.com/monero-project/meta/issues/690
20:33:24 <selsta> sethforprivacy: it doesn't have to be merged before binary release
20:33:38 <selsta> there can be a second release with wallet updates to support hardware wallets, we have done this in the past
20:34:25 <selsta> seeing that there is no reply from ledger at this point, it will likely require second release
20:37:51 <sethforprivacy> selsta: Good to know, thanks!
20:49:16 <selsta> also we have to think what we will do about ledger
20:49:38 <selsta> jberman[m] might have to help here with the integration :D