Alright nonstandard fee hunters. Here's your treasure map: github.com/Rucknium/misc-research/tree/main/Monero-Nonstandard-Fees

Lyza: ^

MRL meeting in this room in one hour

Meeting time! monero-project/meta #901

1) Greetings

<v​tnerd:monero.social> Hi

Hello

2) Updates. What is everyone working on?

<v​tnerd:monero.social> Me: subaddressses in lws.

me: Created some data tables to help "someone(s)" to track down which wallet implementations may be producing nonstandard fee txs: github.com/Rucknium/misc-research/tree/main/Monero-Nonstandard-Fees

i have some major improvements to fee normalization for lws clients fwiw

publishing momentarily

not sure if i should mention it so soon but i even normalized tx creation code

(discarding my custom entrypoint to cryptonote tx utils)

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?

Thanks. How do your improvements interact with jberman's fixes to MyMonero's fee calculations?

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?

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

Yes, I think those fixes.

it supersedes them.. no need for them

they ensure decoy out pinning to previously chosen spendable outs

wallet2 code does that naturally

brb

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

But not sure whether those people would be ready to transact and then send the tx id somewhere, for inspection

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.

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.

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.

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

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.

Sure. We are talking a little past each other, maybe :) I am thinking about the proverbial "grandmother" at the smartphone Monero wallet

But never mind, will think about a little more

hello

I agree that this treasure hunt isn't for grandmothers :)

oops

i'll have to go back and check. I did say that without full confirmation.

plowsof: Did you have an update?

anyway, if the fee is actually stored as a variable length, it should probably be padded for fungibility

It looks like we are already in 3) Discussion. What do we want to discuss?

If anything, what plowsof reported in Monday's wallet workgroup meeting, log here: monero-project/meta #898

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

So we would need to raise about 13,000 USD more in a new CCS, correct?

Because we have ccs.getmonero.org/proposals/bulletproofs-pp-peer-review.html

Looks like that to me

correct, more funds would have to be raised / come from somewhere.

Probably MAGIC would be willing to host the fundraiser. CCS could too, of course.

Is there somewhat more to do than assumed back in March when we did the original CCS?

I mean, for CypherStack

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)

plowsof: Has anyone given any reasons not to raise the rest of the funds for BP++ peer review?

this is the first time sharing the new price

Have any Monero-associated cryptographers commented about whether zksecurity would be a good firm to do the job?

I also wonder a bit who would go into concrete negotiations with them, as a question of organisation on our side ...

"We tried, but couldn't construct a math proof of security" is a possible outcome. That makes this tricky.

Anyway, the list of "our" cryptographers is not that long, probably UkoeHB, Tevador, kayabaNerve and maybe lately and upcoming Jeffro256

<k​ayabanerve:matrix.org> jberman:

<k​ayabanerve:matrix.org> I believe they reached out to ZkSecurity, though I may be thinking of a different firm.

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)

$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

Well, yes, devs use to make 3 months CCSs, but for cryptographical work I think we could easily be more flexible

Isn't the scope Gist supposed to provide deliverables? We're dragging this out.

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

and only then move up into six figure regions

ok, pin them on this gist.github.com/plowsof/8cb33e2efe4bf0239927ad3bd92326e0 and receive the quote/timescales from Zksecurity + CS?

The root of this problem is laying down a protocol and code without security proofs to back them up.

People who don't do cryptography (rbrunner, plowsof, me) cannot do this part of the project IMHO.

+1

<j​berman> The third bullet point would be blocked until the address spec is settled, but creating a formal security model would not be*

That's just a little additional problem on top of it all :)

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.

Maybe some of those cryptographers reads this log and is in the mood to take the lead here

*Maybe one

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.

Agree. Such things tend to go astray anyway if you try to force them. True interest probably has no substitute.

Let's wait and see a bit, Monero usually muddles through somehow.

Bring back Triptych. It has security proofs :)

Isn't that even implemented as well?

I don't know. We can close the meeting here. Thanks everyone.