Hello. Here's a "demo" of how the key image bug works: github.com/coinstudent2048/junks/blob/master/key_image_bug.py

dangerousfreedom the "simplest mitigation" part is what we can add in your checker. This is the use of the feature I added in `dumber25519 . py`.

> <@coinstudent2048:matrix.org> Hello. Here's a "demo" of how the key image bug works: github.com/coinstudent2048/junks/blob/master/key_image_bug.py

> dangerousfreedom the "simplest mitigation" part is what we can add in your checker. This is the use of the feature I added in `dumber25519 . py`.

Awesome! I will check what you did and create a section on the pre-ringCT explaining it (and citing you of course). Thank you very much coinstudent2048 !

Meeting 2hr

meeting time monero-project/meta #682

1. greetings

hello

Hi

Hi!

yoroshiku!

howdy

Hello

Hi

2. updates, what is everyone working on?

I think I understand MLSAG signatures now :) I will soon start writing about it. Can I use some of your phrases in ZtM, Koe ?

go for it

I'm currently looking through xmr-ack's current work to see what kind tx fee analysis I can contribute

hi

should have something neat to share in a couple weeks

My effort to uncover nonstandard Decoy Selection Algorithms (DSAs) by partitioning transactions by `unlock_time`, `tx_extra`, etc. has been bearing fruit. Not ready to share publicly yet. I think we should seriously consider enforcement of a standard DSA at the node rebroadcast-level in the hard fork after this upcoming one.

Eventually I hope to understand UkoeHB 's "deterministic" ring member selection proposal here:

me: Still plugging away at seraphis multisig tx builders. I've been thinking about some software design ideas like correct by construction and validating preconditions. Multisig tx builders have this problem where a malicious participant could provide a malformed piece during a tx building ceremony that doesn't cause a failure until the final step. Trying to duplicate all tx semantic rules into custom semantic checkers

isn't robust/easy, and isn't easy to extend to match hard fork rule changes.

I am also reading a bunch of statistical methodology papers.

Me: I'm currently processing a preliminary dataset using gingeropolous server in hopes to start heavily focusing on feature engineering and also writing up my progress report for MAGIC

Me: on a "background sync mode" where the client uses just the view key to scan for incoming tx's that can be enabled/disabled, I was unsure (and am now more sure) how to proceed in a way that makes the feature most useful for a mobile wallet in practice. I believe upon enabling the mode, wiping the spend key from memory would be a tangible security improvement if e.g. a user has been idle for a long time. Can see my thoughts

here: m2049r/xmrwallet #785#issuecomment-1067482984

Maybe more -dev than -research-lab not sure

I've also spent some time studying the multisig stuff again. I hope to eventually be able to provide a valuable review on this work some day in the near future and fully understand the attacks it is mitigating, though I'm still a ways off in my training. So I'm studying it more in my free time to try to "get there". I will probably get back over to reviewing other PR's (like rbrunner 's reducing trips to daemon PR) today

Hurray :)

3. discussion, any topics to discuss, questions, comments?

I do have a question I was curious about

With Seraphis, which is a massive change which will require new keys already, why not take advantage of the breakage and move to Ristretto?

Our entire crypto library is geared to ed25519, it would be a massive undertaking to implement an entire new library.

and we would have to keep the "old" one anyway. We would carry around two libraries, right?

Do you mean from an optimization standpoint regarding the various types with various properties? Or from an existence standpoint? Because it wouldn't be an entire new library vs just changing the frombytes and tobytes functions

rbrunner: And because of this, adding new from/to bytes functions

Was just thinking that "taking advantage of the breakage" is relative if you basically double the crypto code ...

I do understand not wanting to add extreme levels of technical debt. I just, immediately, don't actually believe it has any significant level of debt as it's functionally an encoder/decoder over Ed25519 and not actually a new curve

The win would be some speedup, I guess as a (still) crypto noob?

rbrunner: Thankfully not the case. I think the main issue post-impl would be the existing rct::key type would have to be deprecated for seraphis::key as rct::key is already encoded and uses the existing encoding functions. It's just a slight annoyance

Is maxwellsdemon here?

Ristretto removes torsion and guarantees canonical encodings at all times. It prevents two Ed25519 libraries from disagreeing on signatures if a signature isn't normal because everything must be normal. While Monero doesn't use traditional signatures, already bans torsion and canonicity, and isn't really looking for a multi node future, I just personally believe canonicity may be one of the most important things in

cryptocurrency and that ristretto is the way to do it for ed25519

Sightly faster equality checks, sightly slower encode/decode IIRC. It's basically just those pair of functions over an Ed25519 lib and we'd still keep all the Ed25519 arithmetic and point types.

I personally don't have the time/bandwidth to implement Ristretto. If someone can present a fully-featured library of manageable size that interfaces with the existing Ed25519 ops, then I would consider converting the existing seraphis library to use that.

It also voids the need to multiply by 8 and I think I saw an issue saying small scalar multiplication wasn't optimized.

UkoeHB: Got it. Completely understandable. Thanks for the heads up

Ristretto requires that group elements only be constructed by decode and from_uniform_bytes. So, hash to point would need updating as well

iirc the dalek ristretto library has a hash to point algorithm

Yeah, we have tons of code to implement and rework for Seraphis anyway, I am already dizzy thinking who will do all that, maybe moving even more is a luxury we simply can't afford ...

If I have time (haha) I plan on writing my implementation to be ablr to use both

as nice as it would probably be

Ristretto specifies Elligator 2 as THE hash to curve algorithm

I am not an optimize coder so there wont be a perfect comparison

While I think it'd be great for XMR to standardize on a modern hTC it should be possible to preserve the existing one and its benefits

rbrunner: I'll probably step up here when I have a moment and given how people use wallet2 all the time, this will hopefully have minimal impact on wallets. For tooling, they'll need to update as they already did, but there is R for C/C++, JS, Rust, Zig...

Maybe we will replace wallet2, just saying :)

And I'm actually not sure if the existing hTC has benefits over Elligator. It just should be technically possible to keep it

I can't wait for wallet4 personally

:)

Is there anything useful / sensible to discuss in this forum regarding hardfork preparation, and as preparation of Saturday's dev meeting?

mul8 does three doublings. It's fast AFAIK.

Got it. That may just be other small scalars then or I may be confusing my issues. Thanks for reminding me of mul8 :)

yeah ristretto would probably only give us on the order of 1% performance gains

variable base scalar multiplication is the main expense we pay for everything

AIUI, the benefit of ristretto is ensuring we never forget to ensure points are in the expected subgroup (or whatever the correct term is).

right

rbrunner: don't think so

Alright, thanks

anything else people want to discuss?

I would find it helpful if someone(s) could help convert the C++ code for old Monero decoy selection algorithms to mathematical expressions. jberman is working on the current one. My hypothesis is that some nonstandard wallets are using the older decoy selection algorithms.

I can see the historical empirical distributions here:

But having the mathematical expressions for them would be a big improvement since it is tough to work with the empirical estimate. And it's less precise.

Old as in, the triangular one ?

Or earlier ?

It was uniform and then triangular at one point, I believe.

Yes. Then uniform with an exception for recent outs, I forget the details.

I think triangular is a priority, and then any earlier ones are a lesser priority.

I think I saw a mathematical version of the triangular pick, but I have no idea where. IIRC smooth made that change, he might know.

Rucknium[m]: I think dr_overdose may be capable of that. May be worth asking if he can and would. He seemed to be interested in contributing.

wernervasquez: Sounds great. I will reach out.

Ok I think we are at the end of the meeting. Thanks for attending everyone