Meeting in two hours.

my update for the meeting: I replaced seraphis view-tag scanning with tevador's mx25519 library to speed it up. Next I will work on integrating legacy inputs into the tx protocol so legacy enotes can be spent in seraphis txs.

nice

Meeting time: monero-project/meta #728

1. Greetings

Hi

Hello

Hi

Hello

hello

2. Updates, what's everyone working on?

Me: OSPEAD work. Reviewing xmrack 's work. Also, took an inventory of which multicoin wallets survived the hard fork. It's been a bit of a bloodbath.

I’m doing last minute editing on my final report for the MAGIC grant. It should be released later in a post to reddit and matrix

xmrack: Do you want to discuss the results during this meeting, or wait until next one?

I think we can do that next week once everyone has given the report at least a skim

I think most, if not all, multicoin wallets depend either directly on MyMonero, or copy technology from there, and if MyMonero is late, a bloodbath results ...

I don't think all of them rely on MyMonero. Here's my list, with date of fix:

rbrunner: Why would a wallet like MyMonero be so late with an update when they hold themselves out as mainly being a Monero wallet? Doesn't make sense.

me: submitted wallet<>daemon hard fork compatibility PR (8544) and started looking into the borked multisig seed recovery: monero-project/monero #8537

Wookey (Aug 19), Exodus (Aug 25), Edge (Aug 27), MyMonero (Aug 29), Not yet fixed: Atomic, Coinomi, Guarda, Zelcore.

no tangible updates on my end from last week on getting multisig security proofs done, but figure it's worth sharing I'm also considering approaching Cypher Stack/Sarang to discuss working with them as well

If anyone has different info, let me know. I have gathered info from Twitter and Reddit.

one-horse-wagon: complicated story, they detailed their woes and their bad luck on Reddit.

In a few months I may submit another CCS to (1) Evaluate safety of altering the wallet2 decoy selection algorithm when not at a hard fork; (2) Prepared an OSPEAD manuscript for submission to an academic journal; (3) Evaluate different methods for transitioning decoy selection for Seraphis transactions.

rbrunner's "no wallet left behind" for Seraphis seems to be particularly important given the recent hard fork wallet bloodbath

Yes, that hardfork will be several orders of magnitude bigger than this comparatively small update

And if you don't prepare you will miss for more than a few days :)

Even nowadays we can discuss wallet upgrades being annoying thanks to items such as Polyseed :/

I havent been around for many hardforks. Was what we saw with v15 normal? Should we consider giving more time for subsequent forks?

*just in how it's a different seed format. I personally greatly appreciate it and believe it should be used.

Rucknium: Where would you place OSPEAD public disclosure in this timeline?

I don't think the MyMonero fumble this time around was a normal occurrence

How many other coins have hard forks where old tx formats are not compatible? I wonder if some of the wallets didn't understand that they had to take action with the hard fork.

xmrack[m] v15 was more hectic than usual

in terms of wallet support

Or better, disclosure of the underlying problems

and anyone who used wallet2 would have been able to integrate the new library well in advance

MyMonero offered me contracted work to prepare their libraries for the hard fork before the fork. I decided I wouldn't want to work on moving forward a centralized wallet scanning service that has access to view keys (unless the wallet makes it extremely clear what the tradeoff is and tucks the option deep into the config settings rather than defaults it). They were not interested in such a drastic change at this time

Interesting background info

maybe we need to think of a way to _force_ everyone to update _before_ the fork. Like mini-fork or something when new nodes refuse to serve RPC to old wallets

rbrunner: The decision is mostly up to the review panel. Hopefully they will be done reviewing by end of October. If disclosure is cleared, hopefully we can do it in November/December. If no disclosure, then no (2) in my list above.

Alright, thanks. Looking forward to it, as a curious person

ringCT hardfork went pretty smoothly. this is certainly not the first time we've migrated txn formats.

sech1: Isn't that just the hard fork but without the benefits of it

Yeah, and I guess users don't care why exactly their wallets don't work anymore, right?

Mini-hardfork or not

Maybe make the wallets 10 times slower ...

I guess we can't solve 3rd-party developers' lazyness on protocol level :D

Or calculate 10 times higher fees :)

Something like ETH's difficulty bomb

It's unfortunate for users. On the other hand, I am not too sad about the death of wallets that have defects in transaction uniformity.

sech1: You really can't force people to upgrade because some people may go away from Monero for years. As it is right now, they can upgrade their wallets and all is good to go.

They'll just upgrade when they get back?

I'm talking about wallet developers

something like protocol-level warning before the hardfork, so you can still use the wallet but with some limitations

sounds like a lot of effort for not much gain

as it is, they will certainly have limitations once the hardfork occurs ..

Call it natural selection for wallets. Adapt or die.

<sech1> "maybe we need to think of a..." <- I considered this for 8544; would have vastly simplified that PR to just break clients immediately and require they update once the fork code is ready to go. But I think the optimal UX is a smooth update transition where wallets give warnings ahead of time. Plenty of modern apps use an approach like this

As far as avoiding this fork's problems, as basically mentioned above MyMonero uses their own custom client<>lws<>daemon setup; I doubt their setup would be break-able pre-fork to avoid the issue

yes, an RPC call that tells you "fork is coming" is already better than nothing

good wallets will show warnings to users

isn't fork info already available in monerod rpc?

that rpc call is not about upcoming forks

monero-project/monero #8544 adds this data

I also seem to recall that while we were still on regular 6 month upgrades, the daemon would have a timed announcement of "you should be looking for a software update" or somesuch

it was a guesstimate

daemon didn't know the actual fork height

yes...

and was wrong often enough at the end as to basically only annoy

Many of the wallets do not have a check next to their checklist here:

with 8544, if most nodes update well in advance, users will start getting proper warnings

It could be mostly a matter of better communication. Not sure.

perhaps we can add a P2P message to propagate expected update notifications from new daemons to not-yet-updated daemons

hmm, how to avoid fake hardfork P2P messages then?

Signature verification from Core?

using the daemon RPC's get_hard_fork_info would require 2 extra round trips to the daemon to know if client and daemon are both compatible, and also doesn't perfectly handle the case when there is a double fork coming up. The changes I made in 8544 add hf version info into get_version so as to avoid extra trips and more smoothly handle a future multi-fork update like this past one

unless we switch to hardfork voting (aka 90% mined blocks have new version number in the block header).

then the old nodes can start suspecting something :D

actually, we don't even need new RPC to show warnings on the old nodes. major.minor version in the block header is enough to deduct there will be a hardfork soon

feels like this is more of a -dev topic and not -research

true

Well, I still think if you take all MyMonero-related problems out of the picture, and also wallets that hang on a very thin thread anyway for a long time already, not much is left

agreed

a solid number of people reported issues from pointing to outdated nodes in the GUI. 8519 is also supposed to help there

rbrunner: My sentiments exactly.

I wish tevador was here so their interesting proposal could be discussed: monero-project/research-lab #105

Bitcoin had a p2p authenticated message layer. It was never used and there's a reason they didn't restore it

hm, that proposal sounds like can make the commitments both perfectly hiding and perfectly binding at the same time. pretty great.

I'm not personally a fan

The byte increase is minimal. My complaint is it solves one problem yet not another

The other problem being that if you can know the DL of H, you can know the DL of everything else and spend users funds

So between the integration complexity, the privacy concerns (it becomes an end user option), and the remaining unsafeness of classical monero in a pq setting...

My personal advocacy will just be to disable classical monero entirely when the time comes. There's not really another discussion viable

And that's a brutal comment, yet if an attacker can forge the monetary supply, they can presumably also forge auth and it wouldn't be prove-able

So sure, these are neat (minus the privacy concerns which become an end user option), yet they don't create a user safe system. Just a protocol safe system. Due to how incomplete that is, and the privacy concerns, and how it helps Seraphis survive but the need to burn RCT already gives us precedence... I don't believe it's worth the effort.

Isn't counterfeiting a bigger forward-time threat than theft? Users can take action (with enough time) to move their coins to the safer tx type. Are we getting into "turnstile" discussions?

I don't understand half, but are you sure you don't reason along lines of "If I can't make it perfect, I am not in the mood to improve" ...

Rucknium: My comment is that we can prevent protocol inflation, sure, but doing so still leaves an unsafe system not cryptographically secured.

rbrunner: More lipstick on a pig.

:)

To be clear, part of this isn't fully logical, I have an immediate emotional aversion to the privacy implications. While I fully understand this is privacy preserving, I assume wallet2 would by default pick the less private mode, as needed to justify this scheme, which gives me anxiety :/

User keys have to be targeted. Counterfeiting wouldn't require targeting

Wait. Is this pointless?

As in, you have to already know that the target tx output is valuable (which is a point that at least one study on Monero QC resistance has made)

Can't you just still forge the membership proof?

And claim non existent commitments exist without needing to break the existing commitment relationship?

... eh. The argument is we've already upgraded to a PQ membership and are migrating old commitments.

Then yeah, the issue reverts to the fact anyone can migrate anyone's, and a PQ adversary can still violate fund safety. Just on a user level instead of a protocol level. The note is that the protocol enabled that theft instead of preventing it.

Rucknium[m]: In RingCT land, if we used switch commitments, you'd need to factor two points and do a 2^64 brute force (feasible even now) to gain access to an output.

So yes, it's targeting, and yes, it's 2 per-output, not 1 and $$$. Targeting alone isn't necessarily hard though.

Statistical analysis, getting an exchange to send to you and noting the change...

So beyond my personal privacy based aversion, my question becomes do we want the monero protocol to enable theft, yet prevent inflation? Why wouldn't we want to prevent both? It's a UX/security trade off and I'd rather pick security so we do properly communicate there is NO migration in the future and you MUST do it now to preserve your funds.

*in the far theoretical future where we deploy a PQ option and then the existing migration process needs to be deprecated due to a QC being near

You propose a cut-off date for spendability of RingCT based outputs at some time in the future?

rbrunner: it's needed even with the above proposal.

The above proposal would only have Seraphis commitments be secure against inflation in a setting with a quantum adversary.

Hmmm, and how would you make a new RingCT output then, after the Seraphis hardfork?

A forged one

Ah, maybe you don't forge a bad output, just a bad proof?

I'm using the inevitability of the death of RCT outputs, and the remaining insecurity of Seraphis with a quantum adversary, to argue for the death of Seraphis in however many years however, instead of user insecurity with protocol security where the protocol enables an attacker it knows about to profit.

... I was thinking this can be forged at time of spending. Does it need to be forged at time of creation? 🤔

... it really depends on the proof to migrate from an ECC commitment to a quantum one, I guess.

But if it was only forge-able at time of creation, we wouldn't need switch commitments :p

And I believe it's forge-able without issue at time of spending *so long as you have an amount that isn't completely invalid*

I understand even less now, but I am pretty sure a cut-off date for spending of any XMR won't fly anyway.

Cool, that'll cause inflation by a QC in 20 years

:p

I shiver in fear :)

It's already a requirement for protocol security. This proposal means the protocol is secure even under a QC, but users are still left unsafe.

So if we already need to force users to migrate 20 years from now due to a QC, I'd rather ensure they migrate before necessary and not let a quantum adversary steal funds.

So I personally appreciate this proposal, and it does offer protocol security increasing the amount of XMR we don't have to cut off, yet it doesn't achieve safe long term storage of funds which is the reason why we don't want to cut off outputs.

Maybe I should read that CCS-funded QC report 🤔

So it misses the point IMO

*while increasing the amount

I'll post my thoughts on the issue. I've talked here long enough :p

Certainly a good idea

definitely a good idea to outline on the issue what threats are being addressed

Ok good. We end on a cliffhanger. "Find out next time if Monero will survive the QC revolution" :P

Wrote up a response on the issue. Also very happy to see the more efficient scheme proposed

Thanks. Replied.

I also added an informal security proof. Turns out that the switch commitment scheme has about 94 bits of PQ security.

Ack the theft protection which is great. Nack any dismissal of the likelihood of known addresses. Since this is now constructed as a perfectly hiding solution extending security in a PQ solution with a conversion to a binding solution, I'm interested to include it, but relying on it will be one more discussion and I believe it'll still be inevitable to ban ECC solutions entirely.

But this potentially provides a longer grace period there :)

Thanks tevador for another solid contribution and being willing to talk it through with me :) I think this happened a couple of times now :p

I'll formalize a response on the issue when I get back to my laptop

I’m not following this elgamal commitment scheme. What exactly is stored in the chain, and what exactly are the proofs you need for it to be secure?

Afaict you aren’t actually proving anything about D’, so there is no real binding

Hey everyone, I've finished my final report for my MAGIC grant!

This security audit of Monero's ring signature resilience to AI-attacks proposes three different models, the best of which achieved 13.3% accuracy predicting the true spend of mainnet transactions. This revealed that blockchain metadata could provide a marginal improvement of 4.3% greater than random guessing. To hopefully inspire future works, the code to collect, process, and train ML/DL models, as well as the datasets used, are

freely available on the [Github repo](github.com/ACK-J/Monero-Dataset-Pipeline). The final report, containing all technical details, is also published on the GitHub repo and can be accessed [HERE.](github.com/ACK-J/Monero-Dataset-Pip…rtificially_Intelligent_Attacks.pdf)