00:53:05 WARNING 2022-06-28 00:46:46.0713 StratumServer client x.x.x.x:2679 read buffer is full 00:53:05 WARNING 2022-06-28 00:46:46.0713 StratumServer client x.x.x.x:2679 failed to read response, err = ENOBUFS 00:53:05 NOTICE 2022-06-28 00:46:46.0713 StratumServer peer x.x.x.x:2679 disconnected 00:53:05 P2Pool v2.1 (built with GCC/10.3.1 on May 31 2022) 06:48:01 "While I had a few comments, it..." <- " it seemed competent overall." did you read that report ? 06:48:23 "The discussion against isn't..." <- looks like game of words 06:49:09 Says the person who speaks a lot of them without saying anything. 06:49:55 I had my notes, as did koe, yet they were minor. I think my biggest issue was the incorrect scalar description for ed25519 AND the fact the transcript conflict is impossible under the current monero. 06:50:51 While I don't think their previous report was competent, this one acknowledged the known issues, covered each one, accurately diagnosed our lack of blame, and covered on a few edge cases as it should have. 06:51:29 While part of me feels internally, yes, it is empty, and yes, most of the comments were publicly available so it's hard to know how much they contributed... It's also just code without a fault that's been disclosed 06:52:00 So if it truly is just minor issues, this report is competent. Considering that's my current view of the code, then that makes the report competent. We can never truly know though 06:52:16 But yes, we could know more. It's why I asked your opinion on specific tasks/steps 06:52:32 I have no interest in fighting over rhetoric though 07:12:11 "I have no interest in fighting..." <- judging by lack of definitive statements, there is an interest in fighting over rhetoric, otherwise what's the purpose to play with words ? 07:18:23 https://inference.ag/reports/cakewallet.pdf, "The code review was done by threshold signature specialists Adrian Hamelink and Lucas Meier, with 07:18:23 supervision by JP Aumasson." contains explicit names of people responsible for the content of report 07:18:45 https://community.rino.io/rino-multisig-pr8194-audit-20220627.pdf, doesn't contain explicit names of people responsible for the content of report 07:18:59 definitely a sign of intentional responsibility drop 07:20:05 "6 Disclaimer" both has the same disclaimer section, but 1st one with names, 2nd one without names 07:21:19 "The discussion against isn't..." <- "... which makes us unavailable to actually continue with anything if we fall under that line of thinking." wow, thinking isn't compatible problem solving 07:21:25 * isn't compatible with problem solving 07:45:57 "If ooo123ooo1234567: has..." <- explicit steps: don't review properly -> merge -> release -> exploit -> take responsibility for failure 07:47:24 If your steps are to fail as a contributor and then harm the community, that is on you. I asked for your opinion on a path forward (which you could've said would've been redoing all review so long as you actually commented on what proper review is to you). Since there is no forward progress here, I will no longer ask. 07:48:15 kayabanerve[m]: path forward : admit the above scenario 07:48:25 * above scenario -> ... 07:50:05 this step must be done by others, not by me 07:50:57 "which you could've said would've been redoing all review so long as you actually commented on what proper review is to you" this part makes sense only after 07:58:05 "If your steps are to fail as a..." <- "if your steps are to fail as a contributor and then harm the community, that is on you. ..." merge without proper review - no harm for the community, pointing out possibility of negative scenario - harm for the community; facepalm 09:37:41 is only the account index -> 0,0 <- subaddress index a primary (standard) address or are addresses in different accounts with subaddress index 0 also standard addresses and not subaddresses? 09:38:21 so for example is account index -> 1,0 <- subaddress index a standard address or a subaddress? 09:55:22 Only 0/0 is special cased this way. 09:56:29 more details: https://monero.stackexchange.com/questions/10674/how-are-subaddresses-and-account-addresses-generated-from-master-wallet-keys 12:23:17 can somebody explain why we need to create key derivations when verifying tx_proofs? this line of code: https://github.com/monero-project/monero/blob/9750e1fa103539b3e533455500610aae76e253a5/src/wallet/wallet2.cpp#L11840 Why is verifying a tx_proof tied to the concept of a wallet at all? shouldn't this be a utility function outside of wallet2.cpp? I also saw this issue that touches on this: 12:23:18 https://github.com/monero-project/monero/pull/5332 but I dont get it 100% tbh 15:19:13 binaryFate: please ban frankcryptic: for posting scam 15:20:48 (also for only helping 10 people.. the last guy offered to help 20.. selfish) 15:22:20 Banned and message deleted on the Matrix side. 15:55:24 I was only of like 10 mins, and I missed it. 17:36:39 why does monero-blockchain-import modify the b.raw file? 17:36:43 moneromooo: 17:38:03 * b.raw file? md5sum mismatch before vs after 17:40:25 has UnspentProof been implemented? I haven't found anything related to it in the codebase and PRs. If not, and if that makes sense to implement it as described in Zero to Monero v2, I would like to give it a try 18:10:35 It should not. IIRC it's open readonly. 18:10:55 But if it is, it's likely just a lmdb txn id change. 18:11:54 can't imagine anything that touches the input file in -import