03:39:50 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 03:43:45 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 13:34:47 hello good day 13:34:49 :) 13:34:51 so in the fcmp tree, are all the outputs always on the leaves? 13:35:16 does an input have a path on the tree? 15:29:03 monerobull: Is there a way to get the affected IP address ranges? 15:29:38 MRL meeting in this room in one and a half hours. 15:30:15 maybe there is a deeper record of this somewhere. shodan or similar services should have some data 16:01:37 affected nodes that are within these regions or the range of IP addresses of these regions? 16:03:45 https://ioda.inetintel.cc.gatech.edu/region/3478?from=1733422999&until=1733509399 16:03:45 https://ioda.inetintel.cc.gatech.edu/region/3413?from=1733422993&until=1733509393 16:30:57 rando: Thank you. I do see a few nodes in those ASNs in my historical node IP database. 17:00:37 Meeting time! https://github.com/monero-project/meta/issues/1123 17:00:43 1) Greetings 17:01:01 Hi 17:01:08 Hello 17:01:45 hello 17:01:58 Howdy 17:02:19 hello 17:03:46 2) Updates. What is everyone working on? 17:04:48 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. 17:05:09 > 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]. 17:06:20 Me: FCMP benchmarking and Carrot integration work 17:07:04 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: https://magicgrants.org/2024/12/05/Monero-Fund-2025-Election.html 17:09:04 3) Discussion: preventing P2P proxy nodes. https://github.com/monero-project/research-lab/issues/126 17:09:37 hi 17:10:01 A couple people signed the ban list: https://github.com/Boog900/monero-ban-list 17:10:01 I was waiting to investigate a user-reported issue with subnet parsing on the ban list before circulating it more widely 17:10:37 sech1 just confirmed in #monero-community:monero.social that it does work OK on a windows installation. 17:11:11 So we may be good to spread the announcement: https://gist.github.com/Rucknium/76edd249c363b9ecf2517db4fab42e88 17:11:42 And SethForPrivacy added the ban list to their monerod Docker image. 17:11:55 I'll contact MoneroNodo, too. 17:12:43 Anything else on this agenda item? 17:13:07 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 17:15:42 Do we have any other items anyone wants to bring up before the post-quantum discussion? 17:17:04 Discussion: Post-quantum security and ethical considerations over elliptic curve cryptography https://github.com/monero-project/research-lab/issues/131 17:17:18 SyntheticBird: ^ 17:17:31 right on schedule 17:17:32 hello 17:17:37 sorry for being late 17:19:13 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 17:19:36 In my opinion, if priorities had to be chosen, I would choose to prevent counterfeiting before preventing privacy attacks. 17:20:45 There are elements of the Google announcement especially the error reduction that supports the shorter worst case timeframe 17:21:02 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. 17:21:44 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 now the relative difficulty of attacking one compared to the other 17:22:06 Achieving error correction is certainly nice and interesting, but you still need many, many more qubits. There's the rub, IMHO. 17:22:58 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 17:23:09 barely* 17:23:18 If error reduction improves with the number of qubits l would be concerned 17:24:15 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. 17:24:26 Well, it does in that Google breakthrough, but we are many years into QC prototypes, and still only 100 or so qubits. 17:24:56 This is why Carrot should encode switch commitments now IMO 17:25:04 And possibly including a discussion of a transaprent turnstile that coins must pass through 17:25:44 jeffro256: absolutely. 17:26:35 jeffro256: Could you explain what steps would need to be taken to bring that to mainnet? 17:28:07 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 17:28:11 It would be pretty simple 17:29:14 Cost? 17:29:17 I think you mentioned last week that the byte size growth for that is reasonable? 17:29:30 The byte size growth is 0 17:29:38 But what review of the mathematics and/or code would be required? 17:29:43 The scanning time would go up a couple fractions of a percent 17:30:20 So this is an example of low hanging fruit 17:30:36 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? 17:31:31 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 17:31:48 Then we would just double-check that the el gamal commitment is well formed 17:32:12 Sorry I'm late, mixed up timing. My update: continuing faster FCMP++ tree build, implementing faster torsion checking from @kayabanerve's implementation 17:32:15 And explained in one or two sentences, what whould this buy us? Some method to "evacuate" transactions into QC resistant lands in the future? 17:32:29 Exactly 17:32:59 And without this "stuff" that's not possible then? 17:33:19 El gamal commitments have the property that they are "perfectly binding", which means that not even a quantum computer can fake opening them 17:33:32 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? 17:33:32 Ah, ok, it's about faking 17:33:48 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 17:34:39 Just to QC? Or to any blockchain observer if they are "activated"? 17:36:10 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? 17:37:53 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 17:40:41 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? 17:40:48 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) 17:41:48 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. 17:42:09 Here's a pretty decent article about switch commitments: https://docs.grin.mw/wiki/miscellaneous/switch-commitments/ 17:42:32 This is correct 17:43:24 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. 17:43:50 Hmm, if it's about transactions made after that special hardfork, why do we start to use this scheme already today? 17:43:51 as I currently understand, I don't think this is enforceable in good faith. 17:44:20 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 17:45:04 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 17:45:30 Is there also a good general article about those "turnstiles" somewhere? I think I am lacking in conceptual understanding here. 17:46:09 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 17:46:22 Rucknium: good point. 17:46:41 Otherwise, there is no way to retroactively prove that inflation didn't happen 17:46:51 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. 17:47:13 That probably was a "Oh sh*it" moment ... 17:48:15 So that retroactive proof is the thing we are after with starting as soon as possible 17:48:37 https://electriccoin.co/blog/zcash-counterfeiting-vulnerability-successfully-remediated 17:48:43 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 17:50:02 Well they move first and inflate the whole supply, but they couldn't compete for a specific output 17:50:45 And it depends on how fast they can compute versus how fast everyone else can move their coins off 17:51:03 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. 17:51:47 "counterfeit now" needs a QC I would guess? 17:51:52 Oh yeah, if we activate the switch after the first counterfeited output, then the turnstile is all for naught 17:52:10 rbrunner: https://electriccoin.co/blog/turnstile-enforcement-against-counterfeiting/ 17:52:25 Thanks! 17:53:02 And as *now* there are no working QC to counterfeit, we are still ready in time? 17:53:07 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. 17:53:25 Really :) 17:54:17 > 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. 17:54:43 rbrunner: there is no way to know, and maybe there will never be. all we can do is move ASAP. 17:55:09 For Monero, this would be if more XMR tried to crossed the turnstile than the legitimate supply, the turnstile would prevent that. 17:55:36 chaser: Yeah, if it's not prohibitively expensive 17:56:28 Which right now doesn't look so, if I understand jeffro256 correctly 17:56:41 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 17:57:26 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." 17:57:33 Well, if you counterfeit, why not millions of coins at once? 17:57:51 In a few transactions or so 17:58:18 rbrunner: to not kill your golden goose. 17:59:00 Counting on everybody being able to scam staying resonable? 17:59:21 "Some people just want to see the world burn" comes to mind 17:59:25 unironically the reason cold war didn't transformed into ww3 17:59:57 Yes, but access to atomic bombs was pretty limited. With QCs available that may not be the case. 18:00:02 In the context we are discussing, you need a quantum computer, not just knowledge of a math exploit. 18:01:13 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 18:01:31 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 18:01:41 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. 18:02:18 I see 18:02:38 vtnerd: assuming FCMP++, the specific amounts could still reveal identifying info. 18:02:40 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 18:03:05 thats what I mean, you have to reveal at the turnstile, no? 18:03:26 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 18:03:37 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 18:04:07 A turnstile is arguably an emergency option 18:04:29 vtnerd: you could gain some limited obscurity via multiple inputs, if you have them in the specific account you're transacting from. 18:04:47 That is kind of nice, because as I mentioned I don't really "believe" in QCs yet ... 18:05:26 they’ve primarily been a “money hole” so far 18:05:28 A realistically priced emergency option that we might never need. What is there not to like? 18:05:55 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? 18:06:09 Better than starting to use "post-QC-crypto" that verifies 10 times slower and blows up transaction size 10 times 18:06:39 Just the turnstile transactions 18:06:41 At least with current "state of the art" 18:06:50 Yes, switch commitments seem like a good compromise. IIRC, MRL has discussed them years ago, too. 18:07:27 Yes, the idea was circulating years and years ago, though never acted upon 18:07:56 And then we already had quite spectacular breaches of some of those post QC themes mere months after they were proposed. Slendid. 18:08:07 *post QC schemes 18:08:32 The cure might be worse than the desease here :) 18:09:01 I get that those el gamal commitments are well understood and rock solid. They do what they claim, so to say? 18:09:11 rbrunner Nist standardized algorithms seems to be in good course at the moment 18:09:44 Yeah, I was remembering some candidates flopping, not the victors 18:10:02 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 :) 18:10:19 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. 18:10:27 escapethe3ra: ^ 18:11:22 *kind 18:12:22 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 18:13:34 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 18:13:35 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. 18:13:52 lol you put one backdoor in random number generator algorithm, and suddenly no one trusts you ever again. What a fail 18:13:57 I agree, I just assume this uncertainty is what put many reviews from independent researchers upon the NIST standardization process. 18:13:58 Do we have a rough idea of the cost of the post quantum cryptography in terms of tx size and verification time? 18:15:34 ArticMine: may be outdated, but yes: https://gist.github.com/tevador/23a84444df2419dd658cba804bf57f1a#5-post-quantum-signature-algorithms 18:17:05 (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) 18:18:16 Maybe someone starred it in the last week 18:20:12 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 18:21:11 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 18:21:42 SyntheticBird: I don't know, and I don't know anyone who claims to know. personally, makes me worried something's up with them. 18:22:30 Hoping tevador is ok too. I think he's been afk for long periods of time in the past too 18:23:56 We can end the meeting here. Thanks everyone. 18:24:22 thank you all! 18:24:25 Thanks 18:24:47 thanks 18:25:33 Okay I will begin the Carrot modifications now, should only take a couple days 18:25:40 We can rollback if it's not popular 18:32:22 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 18:33:05 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? 18:33:31 Can you *prove* in any way that this universe allows no "computer" whatsoever to crack hashes? 18:34:29 Because of information loss maybe? 18:35:44 you can't reverse a hash (find THE data that was hashed), but you can find A data that gives the same hash 18:36:42 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 18:36:57 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 prove that you can actually model a random oracle as a hash function 18:37:12 You mean you just iterate through many many collisions 18:38:50 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 18:39:57 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 18:40:37 But there's no known mathematical pathway to attack hash functions in general, though 18:43:42 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 18:44:30 Nobody has any idea there yet - other than sech1's bruteforcing of as many collisions as necessary, at least in simple cases 18:45:44 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 ... 18:46:12 Just brainstorming now :) 18:54:48 Isn't groover's algorithm representing a threat against hashes security level <192 ? 18:55:11 Iirc it roughly divide the security level by to 18:55:13 Iirc it roughly divide the security level by two 19:00:55 Oh I think i'm being confused with symmetric ciphers actually 19:52:04 djb claims the cube root complexity claim isn't accurate in practice: https://cr.yp.to/hash/collisioncost-20090517.pdf 19:52:35 I leave no comment on if it'd still be beneficial to be so conversative or of there's more modern research restoring it. 20:00:35 <0​xfffc:monero.social> FWIW djb is extremely reliable source. 20:46:21 Rucknium: This isn't specifically to you, but you noted on the topic here. 20:46:53 I completely disagree. I'd prefer complete destruction of Monero as an economic unit before we had a critical privacy issue. 20:47:51 The project is worthless either way. I'd rather maintain our promise of privacy and not publish everyone's transaction history. 20:48:55 Switch commitments are a voluntary transition with consent of the owner. 20:49:12 I am fine with a turnstile for the PQ migration though. 20:59:15 thanks for the ping, noted; I assume you'll be chairing the 18th correct? 21:02:19 escapethe3ra: Yes