Meeting 2hr

meeting time monero-project/meta #760

1. greetings

hello

Hello.

Hello

Hello

hi

Hello

2. updates, what's everyone working on?

me: started my big cleanup/review pass on the seraphis library

hello

working on getting my machines together / bp++

vtnerd: does the haskell -> C++ translation seem doable?

Hi

eh I dunno yet sadly, too focused on IT stuff. I'll message you privately by friday

ok thanks

haskell is a bit different, but I should be able to pick up the language

it seems the matrix<->irc bridge is dead

can read along here as an interim solution: libera.monerologs.net/monero-research-lab/20221130

nvm that one doesn't see matrix stuff when the bridge is dead..

is the bridge dead?

Matrix<>IRC bridge seems laggy. Maybe it's just my Matrix home server.

matrix users can read along here: libera.monerologs.net/monero-research-lab/20221130

Shouldn't we all just move to Matrix and be done with it?

one-horse-wagon[: no :D

no

anyway that's not a good topic for the meeting

:)

looks like a 3min lag...

and matrix is not reading IRC

going to be a short meeting

3. discussion, anything to discuss?

ghostway was the straw that broke the bridge's back. N+1 Matrix users. ;)

hi

anyway, do matrix users have any updates to give? looks like IRC is picking up messages 2-3 minutes late

im waiting on a progress update from the BP++ author (for the new paper)

late update: I've been working through stress testing the pool and doing a final review on 8076, hoping to be done by end of week

Rucknium[m]: Lol

No progress on irc as well..

I can set up monero irc if this is blocking

thanks plowsof

No substantial updates. The only feedback I received on the public OSPEAD plan so far was from a Reddit user who asked if OSPEAD tries to account for a possible ongoing flooding a.k.a. black marble attack.

The answer is no it does not. But further research on that could happen, outside of the scope of the current OSPEAD CCS.

1 week sounded pretty ambitious for him, such things always take longer than expected

Any feedback can be placed here: monero-project/research-lab #93

does anyone have comments on the account id discussion that starts here: gist.github.com/tevador/50160d160d2…ment_id=4379590#gistcomment-4379590 ?

Some sort of meta comment, I asked myself what to do if our two prominent cryptographers have different opinions, and consensus seems elusive

But I don't have a good answer. Maybe trying to get comments from kabayanerve, luigi, knaccc as well?

I have a question, can you elaborate on this: "user wallets like the CLI can only support around 6 bits worth of account ids (64) before the UX degrades seriously" -> why do you see this as the case? Seems to be the basis for dividing modes via user mode/automated and I'm not seeing exactly why such division would be desirable

UkoeHB^

so the CLI can support 65k accounts?

how does that UX work?

Ah, it's kayabaNerve

I don't believe accounts are paginated when listing them, nor transfers when listing them, but I don't see why the UX *has* to be poor in that circumstance. I.e. why not just have one mode that cleanly handles a large number

So long as there is a mode which supports a large number

My point is the CLI and similar wallets are all manual-interface-oriented. You aren't going to manually manage more than ~64 accounts from the CLI or a phone app, you're going to use a more enterprise-level wallet.

even if the CLI figures out a UX that works, other wallets can't really be expected to all support 'big account set' mode

I follow. Yea, that's fair

Sometimes known as "You can't optimize for everything at the same time" :)

Maybe the bridge slowdown is retaliation from Matrix.org for slyly bridging #monero

About the discussion there, why would the ux degrade? You could have names for them and identifiers that map to some bytes

Hell, some wallets don't support account *at all* to this day?

rbrunner: right, and that reflects the baseline 'no accounts only indices mode'

ghostway[m]: I think a discussion "Is an UX possible" misses the point. Of course it is.

The argument was there are (at least) two important groups of users that may use accounts in substantially different ways. At least I see the argument that way.

ghostway[m]: the simplest UX is 'list your accounts and click on the one you want to access' - that because a tedious burden for large numbers of accounts

One the one hand you and me with a handful of accounts. On the other side Binance with a 10,000-account wallet, who knows.

We don't really need a system that covers both.

They won't manage their wallet with the CLI wallet.

Aha

ghostway[m]: not consensus, but there are some proposals to embed account ids in the jamtis specification

anyway, are there any other topics to discuss today?

Maybe now that bridge crashed for good - or is restarting?

rbrunner: what you see is happening in other channels as well

Jamtis address checksum proposal: gist.github.com/tevador/50160d160d2…ment_id=4382275#gistcomment-4382275

Can't judge that for lack of knowledge, but I do hope we can use that soon with good confidence. Would be nice to have Jamtis addresses fixed.

I don't really have an opinion on the checksum

My question to tevador basically was "Can we trust that particular polynomial" here: seraphis-migration/wallet3 #37#issuecomment-1329217733

Polynomial checksums seem to be having an issue, but I think it's not something that needs to be discussed now when there's no data about it. So my opinion if any, is to have some tests run on it in the background

And their answer looks convincing to me.

I'm still planning to run some tests on the "M" constant.

Didn't gingeropolous say something about that infrastructure? Maybe we can run those "35 billion polymod evaluations" there :)

tevador: can you document the tests you run so they can be reproduced?

Reminder: if we want to do a search for good parameters, gingeropolous maintains a research computing server for us.

Yes, that!

Yes, would be great if a more powerful machine was available for that. The generator search took me 3 days with 16 cores.

Tomorrow I can write polymod in c++/rust, if you want

Seems like the bridge is working now

"64-thread Threadripper CPU" is what the research computing server has

UkoeHB: OK, I'll comment in the wallet3 issue

ghostway[m]: What is polymod?

What is ran in polynomial checksums, polynomial evaluations

Er, tevador also mentioned "polymod" ...

polynomial modulo

Do we only have that available in some slow language so far then? I am a bit confused.

gist.github.com/tevador/50160d160d2…ment_id=4382275#gistcomment-4382275 tevador made that

I wrote it in python for testing purposes

You mean rewrite this for more speed? github.com/sipa/ezbase32

the bitcoin repo has a very well documented C code for the checksum, ours will be very similar except with a degree 8 generator

generator degree = number of checksum characters

Yes, well seems like it's already implemented, and I started to do it in cuda yesterday, but didn't finish

But doesn't matter, the machine has a big cpu

ok it's the end of the hour so I'll call it, thanks for attending everyone

<rbrunner> "You mean rewrite this for more..." <- Not trying to drag the meeting, but that's not general, it's only for bech32

* Not trying to drag the meeting, but that's not general, it's only for bech32's polynomial

* Not trying to drag the meeting, but that's not general, it's only for bech32's polynomial (ah nevermind, misread, it's what you meant)

<rbrunner> "You mean rewrite this for more..." <- When I start compiling his coding, I get errors and warnings. Not many. But I shouldn't get any at all. Wouldn't you want to check his stuff before you assume it's all well and good?

I used the crccollide tool, which compiles just fine.

O.K. I'll check it out.

If I understood correctly, he meant full rewrite with that as a reference

Don't worry about me, I wasn't really proposing anything, just getting to grasp where was "up" and where "down" with all that stuff.