00:24:21 s/cencorship/censorship/ 00:32:55 hey all, are there any companies/people recommended for audits? wondering if there's any gotos for Monero stuff 00:36:34 elizabeth[m]: you can look at the bulletproof and randomx audits 00:37:12 https://github.com/hyc/RandomxAudits 00:40:06 i think for bulletproofs quarkslab did the most extensive work https://blog.quarkslab.com/security-audit-of-monero-bulletproofs.html 01:20:17 ooo123ooo1234[m]: relevant xkcd: https://xkcd.com/1357/ 01:24:30 endor00[m]: https://xkcd.com/2548/ also relevant 01:50:37 selsta: thanks! 02:20:07 .merges 02:20:07 -xmr-pr- 8318 8324 8325 8326 8328 8330 8331 02:20:48 luigi1111w: ^ and gui too please 03:59:36 anybody here use the monerujo wallet? 07:15:25 is it okay to make integrated addresses with subaddresses? the wallet-rpc tells me no: 07:15:26 {... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/d40c51a098fd5e9f434333c547d57c6b35fb7bdc) 07:16:42 and also it seems like the payment id needs to be specified when I use the primary address 07:16:43 {... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/42ca1847dc054e7b7c8fbfd22c667c5e1c1e8652) 07:16:51 even though the docs says it is optional 07:34:44 No. 07:35:29 moneromooo: why not? is there anything I can read to understand why this limitation exists? 07:35:43 Deemed too confusing. 07:36:01 moneromooo: for the user or the implementor? 07:36:24 IIRC there's some discussion about this on the github PR for the patch that added subaddresses. 07:36:27 The user. 07:37:49 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 spirobel[m]: https://github.com/monero-project/monero/pull/8355 09:34:35 Only the default background refresh uses the chunked method atm. 12:05:34 "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 Yes and yes. 12:29:23 I expect wallet refresh to slow down, as this will preempt the overlap between processing blocks and fetching the next blocks. 12:30:11 Maybe fetching fewer blocks at once, and/or making at least N loops, will mitigate if it proves too much. 12:30:27 In any case, wallet concurrency is very basic now anyway. 12:45:27 "In any case, wallet concurrency..." <- I like that monero-javascript has webworkers, so it is essentially like a multi threaded program. 14:48:07 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 of the contract functions are rigged. Was this concern of mine already accounted for? 14:48:34 s/Was/Is/ 15:05:27 "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 specific parts of the bytecode match 15:05:38 but definitely something really important 16:43:56 .merges 16:43:56 -xmr-pr- 8318 8324 8325 8326 8328 8330 8331 17:32:32 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 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 sethforprivacy: it doesn't have to be merged before binary release 20:33:38 there can be a second release with wallet updates to support hardware wallets, we have done this in the past 20:34:25 seeing that there is no reply from ledger at this point, it will likely require second release 20:37:51 selsta: Good to know, thanks! 20:49:16 also we have to think what we will do about ledger 20:49:38 jberman[m] might have to help here with the integration :D