15:16:28 Alright nonstandard fee hunters. Here's your treasure map: https://github.com/Rucknium/misc-research/tree/main/Monero-Nonstandard-Fees 15:17:01 Lyza: ^ 16:07:56 MRL meeting in this room in one hour 17:00:57 Meeting time! https://github.com/monero-project/meta/issues/901 17:01:07 1) Greetings 17:01:12 Hi 17:01:17 Hello 17:03:37 2) Updates. What is everyone working on? 17:04:18 Me: subaddressses in lws. 17:05:00 me: Created some data tables to help "someone(s)" to track down which wallet implementations may be producing nonstandard fee txs: https://github.com/Rucknium/misc-research/tree/main/Monero-Nonstandard-Fees 17:05:53 i have some major improvements to fee normalization for lws clients fwiw 17:06:01 publishing momentarily 17:06:49 not sure if i should mention it so soon but i even normalized tx creation code 17:07:00 (discarding my custom entrypoint to cryptonote tx utils) 17:07:28 I guess that normal users / non-devs have a hard time to see whether their fee is standard or not when they transact with those wallets? 17:07:29 Thanks. How do your improvements interact with jberman's fixes to MyMonero's fee calculations? 17:08:16 which fixes, his old ones from like 2 yrs ago? one he solicited my feedback on causing me to get banned on a certain github org's repos? 17:08:47 rbrunner: I don't think so. Users just need to check what the fee per byte in the wallet UI tells them. If it doesn't tell them, then they can look up the tx ID on xmrchain.net 17:09:04 Yes, I think those fixes. 17:09:18 it supersedes them.. no need for them 17:09:31 they ensure decoy out pinning to previously chosen spendable outs 17:09:42 wallet2 code does that naturally 17:09:53 brb 17:10:54 I was brainstorming about making a post on Reddit to get broader help, and there all kinds of people would potentially try, also some that have never even seen a block explorer 17:11:23 But not sure whether those people would be ready to transact and then send the tx id somewhere, for inspection 17:11:56 Exact fee calculation seems hard to me. Fee is part of a tx (as a variable integer C++ data type(?)). You have to know what the fee is to calculate the fee based on fee per byte. It's a little recursive. 17:12:44 In the tables I Just tried to get clusters of fees that were far from any standard fee level so I didn't have to think about fees that are very close, but not quite, what wallet2 does. 17:13:42 rbrunner: You can run the xmrchain.net block explorer locally if you have a non-pruned monerod node. So they can avoid any privacy issues that way. 17:13:54 The fee is based on the data size or so-called weight of a transaction, and the fee field is of fixed data size, so it should not actually affect the fee calculation 17:15:20 Ok. I based what I said on Zero to Monero 2.0 "Transaction fee: stored as a variable length integer, so ≤ 9 bytes". I don't know the details of the code, of course. 17:15:35 Sure. We are talking a little past each other, maybe :) I am thinking about the proverbial "grandmother" at the smartphone Monero wallet 17:16:06 But never mind, will think about a little more 17:16:13 hello 17:16:22 I agree that this treasure hunt isn't for grandmothers :) 17:16:57 oops 17:17:06 i'll have to go back and check. I did say that without full confirmation. 17:18:27 plowsof: Did you have an update? 17:18:34 anyway, if the fee is actually stored as a variable length, it should probably be padded for fungibility 17:20:47 It looks like we are already in 3) Discussion. What do we want to discuss? 17:21:43 If anything, what plowsof reported in Monday's wallet workgroup meeting, log here: https://github.com/monero-project/meta/issues/898 17:21:51 apologies for the late update. for the BP++ peer review from CypherStack - i have added the "out of scope" feedback received after they looked at the new paper (i placed an asterisk on "Efficiency" incase the "Optimised Binary range proofs" point effects that (to be confirmed) but the price, for the new paper will be $32,000 17:23:39 So we would need to raise about 13,000 USD more in a new CCS, correct? 17:24:02 Because we have https://ccs.getmonero.org/proposals/bulletproofs-pp-peer-review.html 17:25:22 Looks like that to me 17:25:40 correct, more funds would have to be raised / come from somewhere. 17:26:24 Probably MAGIC would be willing to host the fundraiser. CCS could too, of course. 17:27:08 Is there somewhat more to do than assumed back in March when we did the original CCS? 17:27:21 I mean, for CypherStack 17:28:52 i have not yet collated initial feedback / replied to zksecurity yet (tooth/ear/gum issues) - but the reply to their interest would be pushing them to agree to a scope of work / concrete deliverables - and aiming for a lower funding cost of $10k/week, and also if possible a '3 month' longer term grant (if they feel that its required) 17:29:09 plowsof: Has anyone given any reasons not to raise the rest of the funds for BP++ peer review? 17:30:38 this is the first time sharing the new price 17:31:02 Have any Monero-associated cryptographers commented about whether zksecurity would be a good firm to do the job? 17:32:33 I also wonder a bit who would go into concrete negotiations with them, as a question of organisation on our side ... 17:34:49 "We tried, but couldn't construct a math proof of security" is a possible outcome. That makes this tricky. 17:34:53 Anyway, the list of "our" cryptographers is not that long, probably UkoeHB, Tevador, kayabaNerve and maybe lately and upcoming Jeffro256 17:35:41 jberman: 17:36:01 I believe they reached out to ZkSecurity, though I may be thinking of a different firm. 17:38:44 zksecurity are interested , the tldr is they need to (after feedback received from some nwlb/mrl members) is to tell us what they plan on doing (with concrete deliverables) for a 3 month time scale which has been the norm for our funding platforms and push for the low end of their rates ($10k/week) 17:40:51 $120k for 3 month seraphis work would have to show its worth ... and then we compare/contrast as cypherstack are also interested in seraphis work 17:41:10 Well, yes, devs use to make 3 months CCSs, but for cryptographical work I think we could easily be more flexible 17:41:37 Isn't the scope Gist supposed to provide deliverables? We're dragging this out. 17:42:38 All on my own I would probably entrust them first with something of smaller size, just to test, say something that could be done in 3 weeks or, like the BP++ stuff 17:42:50 and only then move up into six figure regions 17:42:57 ok, pin them on this https://gist.github.com/plowsof/8cb33e2efe4bf0239927ad3bd92326e0 and receive the quote/timescales from Zksecurity + CS? 17:44:03 The root of this problem is laying down a protocol and code without security proofs to back them up. 17:45:29 People who don't do cryptography (rbrunner, plowsof, me) cannot do this part of the project IMHO. 17:45:36 +1 17:45:47 The third bullet point would be blocked until the address spec is settled, but creating a formal security model would not be* 17:46:47 That's just a little additional problem on top of it all :) 17:47:28 I try to provide some research infrastructure (moneroresearch.info, list of open research questions, technical review on MAGIC committee), but I have limits and I have to focus on my own research. 17:48:00 Maybe some of those cryptographers reads this log and is in the mood to take the lead here 17:48:14 *Maybe one 17:50:08 To be clear, no one owes Monero any labor. If our constraints include "we don't have enough expert labor to move certain projects forward", then I can work within those constraints. 17:51:22 Agree. Such things tend to go astray anyway if you try to force them. True interest probably has no substitute. 17:52:51 Let's wait and see a bit, Monero usually muddles through somehow. 17:53:57 Bring back Triptych. It has security proofs :) 17:54:59 Isn't that even implemented as well? 17:58:04 I don't know. We can close the meeting here. Thanks everyone.