WARNING 2022-06-28 00:46:46.0713 StratumServer client x.x.x.x:2679 read buffer is full

WARNING 2022-06-28 00:46:46.0713 StratumServer client x.x.x.x:2679 failed to read response, err = ENOBUFS

NOTICE 2022-06-28 00:46:46.0713 StratumServer peer x.x.x.x:2679 disconnected

P2Pool v2.1 (built with GCC/10.3.1 on May 31 2022)

<kayabanerve[m]> "While I had a few comments, it..." <- " it seemed competent overall." did you read that report ?

<kayabanerve[m]> "The discussion against isn't..." <- looks like game of words

Says the person who speaks a lot of them without saying anything.

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.

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.

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

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

But yes, we could know more. It's why I asked your opinion on specific tasks/steps

I have no interest in fighting over rhetoric though

<kayabanerve[m]> "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 ?

inference.ag/reports/cakewallet.pdf, "The code review was done by threshold signature specialists Adrian Hamelink and Lucas Meier, with

supervision by JP Aumasson." contains explicit names of people responsible for the content of report

community.rino.io/rino-multisig-pr8194-audit-20220627.pdf, doesn't contain explicit names of people responsible for the content of report

definitely a sign of intentional responsibility drop

"6 Disclaimer" both has the same disclaimer section, but 1st one with names, 2nd one without names

<kayabanerve[m]> "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

* isn't compatible with problem solving

<kayabanerve[m]> "If ooo123ooo1234567: has..." <- explicit steps: don't review properly -> merge -> release -> exploit -> take responsibility for failure

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.

kayabanerve[m]: path forward : admit the above scenario

* above scenario -> ...

this step must be done by others, not by me

"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

<kayabanerve[m]> "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

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?

so for example is account index -> 1,0 <- subaddress index a standard address or a subaddress?

Only 0/0 is special cased this way.

more details: monero.stackexchange.com/questions/…s-generated-from-master-wallet-keys

can somebody explain why we need to create key derivations when verifying tx_proofs? this line of code: github.com/monero-project/monero/bl…253a5/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:

monero-project/monero #5332 but I dont get it 100% tbh

binaryFate: please ban frankcryptic: for posting scam

(also for only helping 10 people.. the last guy offered to help 20.. selfish)

Banned and message deleted on the Matrix side.

I was only of like 10 mins, and I missed it.

why does monero-blockchain-import modify the b.raw file?

moneromooo:

* b.raw file? md5sum mismatch before vs after

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

It should not. IIRC it's open readonly.

But if it is, it's likely just a lmdb txn id change.

can't imagine anything that touches the input file in -import