<j​effro256:monero.social> slave_blocker: finding a C' = C with different amounts is computationally impossible without knowing the discrete logarithm between G and H. A quantum computer can compute h s.t. H = h G, but that still doesn't give quantum computer the ability to actually determine the amount for an existing commitment C

<j​effro256:monero.social> This is because, given commitment C, for *every single* amount value a, there exists some blinding factor z, such that C = z G + a H. Though a quantum computer could calculate any z, given a, they don't know which one was used when the sender made the amount commitment, since they are all equally valid

hello good day

:)

so in the fcmp tree, are all the outputs always on the leaves?

does an input have a path on the tree?

<r​ucknium:monero.social> monerobull: Is there a way to get the affected IP address ranges?

<r​ucknium:monero.social> MRL meeting in this room in one and a half hours.

<m​onerobull:monero.social> maybe there is a deeper record of this somewhere. shodan or similar services should have some data

<b​asses:matrix.org> affected nodes that are within these regions or the range of IP addresses of these regions?

<b​asses:matrix.org> ioda.inetintel.cc.gatech.edu/region…78?from=1733422999&until=1733509399

<b​asses:matrix.org> ioda.inetintel.cc.gatech.edu/region…13?from=1733422993&until=1733509393

<r​ucknium:monero.social> rando: Thank you. I do see a few nodes in those ASNs in my historical node IP database.

<r​ucknium:monero.social> Meeting time! monero-project/meta #1123

<r​ucknium:monero.social> 1) Greetings

<a​rticmine:monero.social> Hi

Hello

<c​haser:monero.social> hello

<j​effro256:monero.social> Howdy

<c​ast9:matrix.org> hello

<r​ucknium:monero.social> 2) Updates. What is everyone working on?

<r​ucknium:monero.social> me: Working on OSPEAD. I can see big changes in the real spend age distribution during the suspected spam earlier this year and in the week of the Binance delisting announcement. That suggests to me that the estimator is working properly, besides all the theoretical and simulation support for that hypothesis.

<r​ucknium:monero.social> > But there’s way too much information to decode the Matrix. You get used to it. I…I don’t even see the code. All I see is [spam attack, delisting announcement, exchange rate volatility].

<j​effro256:monero.social> Me: FCMP benchmarking and Carrot integration work

<r​ucknium:monero.social> I'm stepping down from the MAGIC Monero Fund committee. All 5 seats are open in the election if anyone wants to run for it. Candidacy announcements are due December 31: magicgrants.org/2024/12/05/Monero-Fund-2025-Election.html

<r​ucknium:monero.social> 3) Discussion: preventing P2P proxy nodes. monero-project/research-lab #126

<v​tnerd:monero.social> hi

<r​ucknium:monero.social> A couple people signed the ban list: github.com/Boog900/monero-ban-list

<r​ucknium:monero.social> I was waiting to investigate a user-reported issue with subnet parsing on the ban list before circulating it more widely

<r​ucknium:monero.social> sech1 just confirmed in #monero-community:monero.social that it does work OK on a windows installation.

<r​ucknium:monero.social> So we may be good to spread the announcement: gist.github.com/Rucknium/76edd249c363b9ecf2517db4fab42e88

<r​ucknium:monero.social> And SethForPrivacy added the ban list to their monerod Docker image.

<r​ucknium:monero.social> I'll contact MoneroNodo, too.

<r​ucknium:monero.social> Anything else on this agenda item?

Anyway, if the Windows error is tricky and for example only occurs with some configured languages, you will only ever find out by spreading the list widely

<r​ucknium:monero.social> Do we have any other items anyone wants to bring up before the post-quantum discussion?

<r​ucknium:monero.social> Discussion: Post-quantum security and ethical considerations over elliptic curve cryptography monero-project/research-lab #131

<r​ucknium:monero.social> SyntheticBird: ^

<s​yntheticbird:monero.social> right on schedule

<s​yntheticbird:monero.social> hello

<s​yntheticbird:monero.social> sorry for being late

<s​yntheticbird:monero.social> So yeah I made this issue because I did realize that deanonymization of monero is inevitable as everyone knows it but actually it is still coming in a few years, precious years that can be harvested now, decrypt later, or used for our users to delete their data that could link their transactions graph to a specific account/personal data

<r​ucknium:monero.social> In my opinion, if priorities had to be chosen, I would choose to prevent counterfeiting before preventing privacy attacks.

<a​rticmine:monero.social> There are elements of the Google announcement especially the error reduction that supports the shorter worst case timeframe

Just a little info where I stand regarding "while most optimistic scenarios expect it to happen in ~10-25 years". Personally I don't believe that. I see at least a 50/50 chance that QC will never work as feared.

<r​ucknium:monero.social> Here's my hypothesized threat model: For the first few years of a quantum breakthrough, there will be a few computers and an adversary won't be able to attack everything all at once. To achieve meaningful de-anonymization, the adversary would have to attack a large number of Monero keys. To attack Monero through counterfeiting, the adversary has to counterfiet just once. I don't k<clipped message

<r​ucknium:monero.social> now the relative difficulty of attacking one compared to the other

Achieving error correction is certainly nice and interesting, but you still need many, many more qubits. There's the rub, IMHO.

<s​yntheticbird:monero.social> rbrunner yes. Google have only 105 qbuits but Atom computing for example have a 1000 qubit prototype that is beraly usable because of error correction

<s​yntheticbird:monero.social> barely*

<a​rticmine:monero.social> If error reduction improves with the number of qubits l would be concerned

<r​ucknium:monero.social> And preventing counterfeiting has political issues. It could be good to start the discussion now. I mean "political" as an economist would call it "distributional". Potential winners and losers. Losers could be users who don't move their coins for years, then are preventing from spending their pre-QC-resistant coins.

Well, it does in that Google breakthrough, but we are many years into QC prototypes, and still only 100 or so qubits.

<j​effro256:monero.social> This is why Carrot should encode switch commitments now IMO

<r​ucknium:monero.social> And possibly including a discussion of a transaprent turnstile that coins must pass through

<c​haser:monero.social> jeffro256: absolutely.

<r​ucknium:monero.social> jeffro256: Could you explain what steps would need to be taken to bring that to mainnet?

<j​effro256:monero.social> Simply change the Carrot blinding factor derivation from a hash of some values X, to a hash of an el gamal commitment, which has a blinding factor as a hash of some values X

<j​effro256:monero.social> It would be pretty simple

<a​rticmine:monero.social> Cost?

I think you mentioned last week that the byte size growth for that is reasonable?

<j​effro256:monero.social> The byte size growth is 0

<r​ucknium:monero.social> But what review of the mathematics and/or code would be required?

<j​effro256:monero.social> The scanning time would go up a couple fractions of a percent

<a​rticmine:monero.social> So this is an example of low hanging fruit

<r​ucknium:monero.social> Would that mean that a blockchain observer would be able to tell if a tx was made with a Carrot or legacy address? Is that already the case without switch commitments?

<j​effro256:monero.social> I think a security proof that the blinding factor brings the same hiding properties as defined already in Carrot would be pretty straight forward since scalar-point multiplication is a 1-to-1 function if the scalar is reduced and the point is of prime order

<j​effro256:monero.social> Then we would just double-check that the el gamal commitment is well formed

<j​berman:monero.social> Sorry I'm late, mixed up timing. My update: continuing faster FCMP++ tree build, implementing faster torsion checking from @kayabanerve's implementation

And explained in one or two sentences, what whould this buy us? Some method to "evacuate" transactions into QC resistant lands in the future?

<j​effro256:monero.social> Exactly

And without this "stuff" that's not possible then?

<j​effro256:monero.social> El gamal commitments have the property that they are "perfectly binding", which means that not even a quantum computer can fake opening them

<r​ucknium:monero.social> IIRC last meeting you said that a revealed switch commitment would create transparent amounts. Is it possible to keep the amount confidential in a smooth transition to post-QC if some more math/code is developed? Is the switch commitment mostly a prep for an emergency QC breakthrough?

Ah, ok, it's about faking

<j​effro256:monero.social> The reason we don't use them is that they are 2x bigger, and would retroactively reveal the amount to quantum computers in the future

<r​ucknium:monero.social> Just to QC? Or to any blockchain observer if they are "activated"?

I am bit confused. If those el gamal commitments are 2 times bigger, and we start to use them, how does the bytesize of a tx not grow?

<j​effro256:monero.social> It depends on how we do it, but confidentiality probably wouldn't work since AFAIK, range proofs on El gamal commitments rely on the hardness of the discrete log problem, which are assuming doesn't exist anymore if we're activating switch commitments

<r​ucknium:monero.social> How could a turnstile work with this setup, to make sure that the total supply of XMR was not affected by a hidden QC attack? Or some other method that had the same effect as a turnstile?

<j​effro256:monero.social> rbrunner: great question. We set the blinding factor in the Pederson commitment to a hash an the el gamal commitment with the same amount value. QCs can't reverse hashes and thus for a given commitment C, and arbitary amount a, can't find blinding factor z, such that C = a H + z G and z = Hn(some el gamal commitment)

<c​haser:monero.social> rbrunner: IMHO "evacuation" isn't the right description. IIUC what it enables is flipping a switch in a fork, which, from the moment of activation (but not any time before) prevents a potential quantum adversary from counterfeiting, but will reveal amounts of transactions made after the activation. it doesn't allow you to detect or roll back any previous counterfeiting.

<j​effro256:monero.social> Here's a pretty decent article about switch commitments: docs.grin.mw/wiki/miscellaneous/switch-commitments

<j​effro256:monero.social> This is correct

<c​haser:monero.social> a turnstile would in this context would mean whoever moves their coins "last" (=before the counter on the turnstile is exhausted) loses their money. you can bet the QC attacker will move first.

Hmm, if it's about transactions made after that special hardfork, why do we start to use this scheme already today?

<c​haser:monero.social> as I currently understand, I don't think this is enforceable in good faith.

<j​effro256:monero.social> So the turnstile would only work to verify that the new transaction output pool was funded by for inputs which 1) use el gamal commitments, and 2) actively prove on those el gamal commitments. Inflation can still occur if we allow new pre-QC outputs to be created with an immediate proof

<r​ucknium:monero.social> The absence of move by a QC attacker means that the supply was not compromised. If the QC attacker moves first, then it's known that the supply was compromised and the system is destroyed. Better to know the system is destroyed

Is there also a good general article about those "turnstiles" somewhere? I think I am lacking in conceptual understanding here.

<j​effro256:monero.social> rbrunner: we start today because the commitments we make today have to be constructed according to a special rule that allows us to reveal that we committed to an el gamal commitment when constructing our Pederson commitments

<c​haser:monero.social> Rucknium: good point.

<j​effro256:monero.social> Otherwise, there is no way to retroactively prove that inflation didn't happen

<r​ucknium:monero.social> Zcash has them for its shielded pools. IIRC, Zcash implemented them after they realized the supply in one of their shielded pools could have been counterfeited.

That probably was a "Oh sh*it" moment ...

So that retroactive proof is the thing we are after with starting as soon as possible

<r​ucknium:monero.social> electriccoin.co/blog/zcash-counterf…lnerability-successfully-remediated

<j​effro256:monero.social> Also, a quantum computer cannot "move first" if make the commitments switch commitments, since they do not know the correct opening of the amount commitment, and it would take about (256-64)/2 bits of brute forcing to find a valid opening for *any* amount

<j​effro256:monero.social> Well they move first and inflate the whole supply, but they couldn't compete for a specific output

<j​effro256:monero.social> And it depends on how fast they can compute versus how fast everyone else can move their coins off

<c​haser:monero.social> I meant "move first" as in 1) counterfeit now (before the chain is upgraded to switch commitments), then 2) go to the turnstile as soon as that becomes part of consensus.

"counterfeit now" needs a QC I would guess?

<j​effro256:monero.social> Oh yeah, if we activate the switch after the first counterfeited output, then the turnstile is all for naught

<r​ucknium:monero.social> rbrunner: electriccoin.co/blog/turnstile-enforcement-against-counterfeiting

Thanks!

And as *now* there are no working QC to counterfeit, we are still ready in time?

<c​haser:monero.social> as I love this specific blog for from Zcash/ECC so much, I have to point out that their claim to be able to somehow detect whether inflation took place before the fix is wholly unproven and they refused to show any proof of it.

Really :)

<r​ucknium:monero.social> > If a counterfeiting compromise generated illegitimate ZEC within a shielded value pool and more ZEC exited the pool than entered, then the publicly tracked value pool total would become negative.

<c​haser:monero.social> rbrunner: there is no way to know, and maybe there will never be. all we can do is move ASAP.

<r​ucknium:monero.social> For Monero, this would be if more XMR tried to crossed the turnstile than the legitimate supply, the turnstile would prevent that.

chaser: Yeah, if it's not prohibitively expensive

Which right now doesn't look so, if I understand jeffro256 correctly

<r​ucknium:monero.social> And the attempt should show that someone did counterfeit XMR somehow. But the turnstile would prevent more than the legitimate supply from existing on the other side of the turnstile. Legitimate XMR by users who did not move "in time" would be lost to those users

<c​haser:monero.social> Rucknium: true, but that's only if/when enough people wake up and start to move coins and the attacker is smart. my comment concerned this part, about present analysis: "The Zcash Company studied the blockchain for evidence of exploitation: An attack might leave a specific kind of footprint. We found no such footprint."

Well, if you counterfeit, why not millions of coins at once?

In a few transactions or so

<c​haser:monero.social> rbrunner: to not kill your golden goose.

Counting on everybody being able to scam staying resonable?

"Some people just want to see the world burn" comes to mind

<s​yntheticbird:monero.social> unironically the reason cold war didn't transformed into ww3

Yes, but access to atomic bombs was pretty limited. With QCs available that may not be the case.

<r​ucknium:monero.social> In the context we are discussing, you need a quantum computer, not just knowledge of a math exploit.

<v​tnerd:monero.social> any privacy concerns related to the turnstile? I guess its better than having no technique for confirming inflation, but the problem is that in the end all you can do is block people at the turnstile or declare monero dead

If we can get those switch commitments in in a year's time or so, I can take the risk / probability of QCs appearing in that short timeframe

<c​haser:monero.social> rbrunner: world burners exist, and a single one could blow up such a potential balance. I can't prove or disprove it, only say that a situation where that doesn't happen is possible.

I see

<c​haser:monero.social> vtnerd: assuming FCMP++, the specific amounts could still reveal identifying info.

<r​ucknium:monero.social> AFAIK, with a turnstile an observer would see that a specific turnstile tx had a certain XMR amount, but without rings, there is very little info for an adversary to get about the tx graph or any info before or after the turnstile

<v​tnerd:monero.social> thats what I mean, you have to reveal at the turnstile, no?

<j​effro256:monero.social> Realistically, we would probably have to downgrade the privacy of turnstile transactions to that of BTC (with stelath addresses): so no amount privacy and no sender privacy. This is because our current FCMP++ unspentness and ownership proofs rely on the DLOG problem, so we will need new sender proofs basically

<s​gp_:monero.social> There are serious privacy risks, but when compared to the alternative of a possibly counterfeit supply, the risks might be outweighed by the advantages. Zcash made the decision that the advantages of the turnstile were worth it. For Monero, sacrificing privacy will be even greater risk

<s​gp_:monero.social> A turnstile is arguably an emergency option

<c​haser:monero.social> vtnerd: you could gain some limited obscurity via multiple inputs, if you have them in the specific account you're transacting from.

That is kind of nice, because as I mentioned I don't really "believe" in QCs yet ...

<v​tnerd:monero.social> they’ve primarily been a “money hole” so far

A realistically priced emergency option that we might never need. What is there not to like?

<r​ucknium:monero.social> jeffro256: Is that a downgrade to the privacy of the "one" entry turnstile tx, or all txs after the turnstile, i.e. all post-QC-secure txs?

Better than starting to use "post-QC-crypto" that verifies 10 times slower and blows up transaction size 10 times

<j​effro256:monero.social> Just the turnstile transactions

At least with current "state of the art"

<r​ucknium:monero.social> Yes, switch commitments seem like a good compromise. IIRC, MRL has discussed them years ago, too.

<s​gp_:monero.social> Yes, the idea was circulating years and years ago, though never acted upon

And then we already had quite spectacular breaches of some of those post QC themes mere months after they were proposed. Slendid.

*post QC schemes

The cure might be worse than the desease here :)

I get that those el gamal commitments are well understood and rock solid. They do what they claim, so to say?

<s​yntheticbird:monero.social> rbrunner Nist standardized algorithms seems to be in good course at the moment

Yeah, I was remembering some candidates flopping, not the victors

<r​ucknium:monero.social> Before we end, I'll announce that I don't intend to post an MRL agenda or chair a meeting for Wednesday, December 25. But people can choose to meet if they want :)

<c​haser:monero.social> rbrunner: yes, this is why Bernstein has been advocating for some king of hybrid (encapsulated?) approach to fend off the risk of new primitives, but I'm not sure how much progress was made into that direction.

<r​ucknium:monero.social> escapethe3ra: ^

<c​haser:monero.social> *kind

<j​effro256:monero.social> I will say that NIST/NSA has a history of pushing unsafe crypto specifically to weaken real-world systems. We should always keep this in the back of heads when considering post-quantum cryptography hype

Well said. And it's so terribly early with all that stuff, if we go for something there, you can be sure we will look like dinasaurs after some better stuff appears

<c​haser:monero.social> I'm arguably nowhere to be able to judge the NIST post-quantum standardization process professionally myself, but the fact that Daniel Bernstein found it concerning does concern me, given that half of our current asymmetric crypto came from him.

<v​tnerd:monero.social> lol you put one backdoor in random number generator algorithm, and suddenly no one trusts you ever again. What a fail

<s​yntheticbird:monero.social> I agree, I just assume this uncertainty is what put many reviews from independent researchers upon the NIST standardization process.

<a​rticmine:monero.social> Do we have a rough idea of the cost of the post quantum cryptography in terms of tx size and verification time?

<c​haser:monero.social> ArticMine: may be outdated, but yes: gist.github.com/tevador/23a84444df2…5-post-quantum-signature-algorithms

<c​haser:monero.social> (unrelated easter egg: the gist says "last active last week", and I'm not sure what that means, given that tevador has been away for months, and no comments have been posted under it recently either)

<r​ucknium:monero.social> Maybe someone starred it in the last week

<s​yntheticbird:monero.social> I wasn't planning on asking the question but I was asking myself, is tevador ok? I haven't seen activity of him since a while

<j​berman:monero.social> Fwiw I would be for switch commitments in Carrot v1, I think it's a sound strategy toward mitigating the worst outcome of hidden inflation at low cost

<c​haser:monero.social> SyntheticBird: I don't know, and I don't know anyone who claims to know. personally, makes me worried something's up with them.

<j​berman:monero.social> Hoping tevador is ok too. I think he's been afk for long periods of time in the past too

<r​ucknium:monero.social> We can end the meeting here. Thanks everyone.

<c​haser:monero.social> thank you all!

<a​rticmine:monero.social> Thanks

<s​yntheticbird:monero.social> thanks

<j​effro256:monero.social> Okay I will begin the Carrot modifications now, should only take a couple days

<j​effro256:monero.social> We can rollback if it's not popular

What I find the most worrysome about all that QC stuff is this: Many people seem to be damned sure about the capabilities that they will have

How can you be sure? QCs cannot crack hashes? How do you know? Are you sure they won't have very different capabilities that people now see in their crystal balls?

Can you *prove* in any way that this universe allows no "computer" whatsoever to crack hashes?

Because of information loss maybe?

you can't reverse a hash (find THE data that was hashed), but you can find A data that gives the same hash

but if you have some extra information (i.e. the data was a readable text of a certain length), and unlimited compute power, then you can probably find it

<j​effro256:monero.social> That's actually an open question in mathematics in general. Us humans have come up with this notion called a "random oracle", an entity which returns a perfectly random, chaotic, yet deterministic answer when given an input. This is what hash functions are designed to emulate. We can prove that a lot of cryptography is safe if these entities exist, but no one has yet been able to <clipped messag

<j​effro256:monero.social> prove that you can actually model a random oracle as a hash function

You mean you just iterate through many many collisions

<j​effro256:monero.social> On the other hand, no one has been able to formulate a place to begin to break random oracles. This isn't the case with elliptic curves, RSA, etc. There is already an algorithm which can do it, given that you can throw some part of the computation at a magical physics phenomenon and get quick answers. It's called Shor's algorithm

<j​effro256:monero.social> So while we don't know for sure what QCs can or can't do since we haven't made them yet at a practical level, we are pretty certain if this "noise" / "error correction" issue goes away, then a QC can use Shor's algorithm to break elliptic curves

<j​effro256:monero.social> But there's no known mathematical pathway to attack hash functions in general, though

So we don't have yet a hypothetical "If QCs can do that then hashes are broken", with only the uncertainty left whether they will or will not be able

Nobody has any idea there yet - other than sech1's bruteforcing of as many collisions as necessary, at least in simple cases

A QC being able to represent so many states simultaniously that they can represent *all* possible byte sequences up to a particular length, and hash them all in parallel ...

Just brainstorming now :)

<s​yntheticbird:monero.social> Isn't groover's algorithm representing a threat against hashes security level <192 ?

<s​yntheticbird:monero.social> Iirc it roughly divide the security level by to

<s​yntheticbird:monero.social> Iirc it roughly divide the security level by two

<s​yntheticbird:monero.social> Oh I think i'm being confused with symmetric ciphers actually

<k​ayabanerve:matrix.org> djb claims the cube root complexity claim isn't accurate in practice: cr.yp.to/hash/collisioncost-20090517.pdf

<k​ayabanerve:matrix.org> I leave no comment on if it'd still be beneficial to be so conversative or of there's more modern research restoring it.

<0​xfffc:monero.social> FWIW djb is extremely reliable source.

<k​ayabanerve:matrix.org> Rucknium: This isn't specifically to you, but you noted on the topic here.

<k​ayabanerve:matrix.org> I completely disagree. I'd prefer complete destruction of Monero as an economic unit before we had a critical privacy issue.

<k​ayabanerve:matrix.org> The project is worthless either way. I'd rather maintain our promise of privacy and not publish everyone's transaction history.

<k​ayabanerve:matrix.org> Switch commitments are a voluntary transition with consent of the owner.

<k​ayabanerve:matrix.org> I am fine with a turnstile for the PQ migration though.

<e​scapethe3ra:matrix.org> thanks for the ping, noted; I assume you'll be chairing the 18th correct?

<r​ucknium:monero.social> escapethe3ra: Yes