meeting 1.25hr monero-project/meta #643

Likely wont be here for meeting but wanted to weigh in on address schemes.

IMO view tags are a must to allow light wallets that dont impact anonymity.

And view keys should show spends and receives to calc full balances without back and forth with offline wallet. Makes the most ux sense to me.

^both of these features are already in the proposal

I will I have some questions

<tevador> "^both of these features are..." <- So, IMO plain D or Janus E aligns users desires for ease with anonymity

the current proposal "Jamtis" is a kind of hybrid between "Janus B" and "Janus E"

Link?

I'm in the process of rewriting the proposal, but here is an older version: gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024

meeting time: monero-project/meta #643

1. greetings

hello

hi

hi

Hi

tevador: are you planning to change the proposal?

I'm rewriting it mostly for better readability, but there are also some minor changes

e.g. the one-time change addresses we discussed earlier

sounds good

also added an "xmr" prefix to base58 addresses as per fluffypony's suggestion

I've also coded a library that will be used for human-readable representation of wallets and addresses: github.com/tevador/id32

ah interesting

2. discussion, does anyone have anything they want to discuss (e.g. from the agenda, or otherwise)? This was Christmas week so it might be a short meeting.

I have been thinking a little about wallet/account architecture, and made a little progress but still not completely nailed down.

Last meeting we discussed reaching out to merchants and crypto services about the preferences regarding the address schemes. We haven't done anything on that yet, AFAIK.

I tried gauging the benefit of binning in protecting a user who spends multiple inputs that are close in age in a tx (e.g. collect change outputs over the course of a day, then spend them >2 months later in the same tx), and found that users seem decently well protected in this scenario already, and that binning wouldn't necessarily be of huge help (monero-project/research-lab #86#issuecomment-1001091949)

This would be a good way to have non-devs and non-researchers contribute -- send them forward to query merchants.

Unless people have objections and want to see the wallet-side binning proposal I shared implemented (monero-project/research-lab #88), I also am leaning toward setting it aside and moving on. It seems like it would be challenging to get everyone on board with it, and the benefits of binning at this stage I don't think are critical

I think this discussion is being watched by some merchants: monero-project/monero #7889

I think that binning makes more sense once we have a greater number of decoys to work with, which will (hopefully) happen later on with Seraphis. We also need more statistical analysis of the benefits and costs of binning before putting it into production, I think.

" and that binning wouldn't necessarily be of huge help " Was that a surprise to you?

What I am saying is that I would agree with returning binning to the back burner, to pick up later.

Or kind of a disappointment?

Haha not a disappointment, I think that finding was definitely a good thing. But I did think binning would be of more help in that particular scenario, considering the gamma isn't specifically designed to protect from it

Interesting

This is only relevant to a specific threat model, correct, jberman?

Your most recent findings, that is.

Yes

theblackdog001[m: did you have a question?

Are we on target for March 15 hard fork? What more needs to be done?

I guess that's a -dev question, but can MRL help at all?

Maybe multisig is the critical path?

I think the multisig PRs are close to merge-able, which is good news.

I will try to get the last review comments from vtnerd wrapped up by this weekend.

Hmm, monero-project/monero #8114 has quite some unaddressed review issues, last time I checked

I wanted to do functional tests, but decided to wait

However don't understand half of the mentioned points :)

I think most of that is just discussion that doesn't require new diffs

I will ask folks at #monero-ux:monero.social if they can do some outreach to merchants, payment processors, etc regarding their preferences on address schemes.

thanks Rucknium[m]

Sounds like a good idea

Seems like we can close out the meeting. Thanks for attending everyone, and merry christmas :)

Cheers

Btw I conducted some personal research into a 50%+1 attack on a proof-of-work privacy coin, and just posted the results at mitchellpkt.medium.com

(yea I know I should self-host instead of using medum, but I’m too absentminded to be a competent sysadmin lol)

isthmus: Nice! Any word on the cconference?

Postponed until May

(The school is closed, so they can't use the facilities during the originally scheduled window)

Oh. Did they give a thumbs up or down on our paper?

No response either way. I suspect that they're going to wait a few months to confirm the presenters to avoid churn from people saying yes now but not showing 5 months later

Makes sense. Maybe we will have new findings by then.

Oh yea I have a ton of ideas for conducting the transaction tree analysis on branches related to the attack

The fast spend time (<15 blocks) will make it pretty easy to deanonymize most of the ring signatures

Especially since right off the bat we can filter out every ring member that doesn't match the known signature

isthmus: Do you know of any introductory resources to chain analysis, for transparent UTXO chains? I am starting to get into it.

isthmus: Very interesting article

18:18 <Rucknium[m]> Are we on target for March 15 hard fork? What more needs to be done? <-- I feel like we lost some time with reviews still being focused on multisig vulnerabilities

at least vtnerd focused on multisig so he wasn't able to approve the BP+ changed yet

also I need some info how much work it will be for hardware wallets to implement BP+

I remember sarang or someone else saying it's less work than CLSAG

but still it's something we have to consider, time availability for ledger / trezor devs is kinda out of our control

UkoeHB: have you already defined the Seraphis base points X and U? I need them to make test vectors for Polyseed + Jamtis.

Final call to be a MAGIC Monero Fund voter or committee member: github.com/MAGICGrants/Monero-Fund

tevador: github.com/UkoeHB/monero/blob/1dafb…c/seraphis/sp_crypto_utils.cpp#L101

I wouldn't say this is 100% set in stone, since none of the code has been reviewed

Updated Jamtis: gist.github.com/tevador/50160d160d24cfc6c52ae02eb3d17024

UkoeHB: thanks, could please copy paste the points X/U in hex? I will use them in my python script

Ok, maybe tonight I can

<isthmus> "(yea I know I should self-host..." <- you don't need advanced sysadmin skills and you can even start by hosting on Github for free if you're not ready for a vps

let me know if you need a hand