17:36:28 <UkoeHB> sech1: https://www.reddit.com/r/Monero/comments/1013vzz/comment/j2m5o0r/ it is forward secrecy against a DLP solver, that’s it
17:37:06 <sech1> DLP solver = quantum computer?
17:38:47 <UkoeHB> Quantum computer is an example yes
17:39:24 <monerobull[m]1> How does forward privacy work sech1
17:39:25 <monerobull[m]1> ?
17:39:39 <monerobull[m]1> * How does forward secrecy y work sech1
17:39:46 <monerobull[m]1> s/privacy/secrecy/
17:39:58 <sech1> no idea
17:40:19 <sech1> something about having a ton of solution to an equation even if you can solve it
17:40:26 <sech1> and you don't know which solution is THE solution
17:40:55 <monerobull[m]1> I see, didn't know that's part of seraphis but pretty cool 
17:42:12 <UkoeHB> Forward secrecy means if a future exploit is developed then stuff created in the past remains secret
17:43:40 <monerobull[m]1> I get that but i didn't know how that could work
17:45:08 <Rucknium[m]> Could a DLP solver create counterfeit coins under Seraphis? AFAIK, a DLP solver can create counterfeit XMR coins today.
17:46:05 <Rucknium[m]> Maybe I should find a citation for that last statement
17:46:51 <sech1> yes, it can
17:48:08 <Rucknium[m]> Source: sech1 (2023)
17:48:31 <isthmus> Also Section 3.3 of https://raw.githubusercontent.com/insight-decentralized-consensus-lab/post-quantum-monero/master/writeups/technical_note.pdf
17:48:52 <sech1> no, it can be concluded from section 5.2 of https://www.getmonero.org/library/Zero-to-Monero-2-0-0.pdf
17:48:55 <Rucknium[m]> isthmus: Thanks. Yes, I was starting to look through that :)
17:49:13 <sech1> "The hardness of the discrete logarithm problem ensures calculating γ from H is infeasible"
17:54:58 <Rucknium[m]> Then would it be a good idea to perform a "turnstile" once we have a tx protocol that a quantum computer cannot counterfeit? Or could the quantum-resistant protocol be structured so that no counterfeiting could be performed on the input side of the transaction (and the quantum-resistant cryptography would be forced to be used in every output).
17:55:34 <sech1> so if γ can be calculated from H by a DLP solver, it can add γ to the total value of the output in a transaction, which will probably be some crazy amount of XMR - around 10^73
18:04:34 <UkoeHB> Rucknium[m]: you’d probably want a sunset on pre-quantum coins
18:04:51 <UkoeHB> On transitioning them to post-quantum*
18:05:00 <UkoeHB> A turnstile is just an invitation to steal from old users
18:06:41 <Rucknium[m]> If there is a sunset, old inattentive users would lose their coins anyway, right?
18:08:26 <UkoeHB> Yes
18:10:27 <sech1> People can leave their coins untouched for years
18:11:00 <sech1> just now we had a user from minexmr in #monero-pools who asked "why not work". 5 months after minexmr clode
18:11:05 <sech1> *closed
18:25:04 <monerobull[m]1> This isnt Bitcoin. If we have to abandon people who don't check in for a year to improve the chain we should.
18:35:45 <dEBRUYNE> ^ Hard disagree, we cannot force users to move their coins
18:45:50 <monerobull[m]1> It's obviously the most drastic measure but if it's necessary for some massive improvements, why not?
18:48:20 <sech1> abandoning OG users is a true shitcoin territory, please no
18:48:29 <rbrunner> Probably depends how things progress further with those fabled quantum computers. I am one of those who say we are not yet even sure they will *ever* work
18:48:42 <rbrunner> in this universe at least
18:52:21 <UkoeHB> I mean, a DLP solver could probably forge key images so I don't think you can continue supporting any pre-quantum indefinitely.
18:53:04 <UkoeHB> sorry no, forging key images doesn't matter because you can drain the entire turnstile in 1 tx
18:53:53 <UkoeHB> it's either a hardfork-defined sunset, or a race to drain the turnstile
18:55:20 <monerobull[m]1> Turnstile would work up until the point actual quantum computers become viable, hardfork could potentially sunset decades prior
19:13:18 <moneromoooo> People can get fucked till (1) turnstile end date or (2) someone manages to generate infinite coins. Best to let them be fucked at the latest possible date. It's thus 2.
19:13:47 <moneromoooo> That is, if you set 1 date earlier, they get fucked earlier (that is, they get less leeway).
19:13:58 <moneromoooo> If you set date 1 later, they get fucked by 2 first.
19:14:19 <moneromoooo> So setting date 1 later is better. Which is equivalent to not setting a date.
19:14:51 <moneromoooo> Unless you view "preventing someone from stealing coins" to be better than "ensuring noone gets their coins arbitrarily destroyed".
19:15:49 <moneromoooo> Not doing harm seems better than letting harm happen (assuming rough equivalance between the amount of harm in either case).
19:16:41 <moneromoooo> At least in this case where you cannot predict when 2 might happen so you can set 1 right before it.
19:17:30 <moneromoooo> There *is* an argument for saying the magnitude of harm to 1 goes down as enough time passes though.
19:17:45 <moneromoooo> But it is pretty subjective.
19:18:36 <moneromoooo> (as in, when one can argue than the time-decreased harm from 1 is less than the potential harm from 2)
19:20:04 <moneromoooo> In a sense I suppose it's similar to the trolley problem actually... With unknown amounts of people on either side.
19:20:42 <moneromoooo> With the added complication that you change the rules midday.
19:22:21 <spackle_xmr[m]> I certainly think there are some design choices that complicate this. Transparent migration (revealing amounts) with a total amount limit would be an example.
19:22:59 <moneromoooo> Why would you want to reveal amounts ?
19:23:15 <moneromoooo> Is this undoable without revealing amounts ?
19:24:06 <moneromoooo> nvm, your wording did not imply that. Ignore me.
19:30:57 <UkoeHB> yeah I'm pretty sure turnstiles must be transparent, because otherwise there is no way to know when you have reached the end condition (put another way - if there is a way to test the end condition then you can always deduce each incremental amount that passes through the turnstile)
19:38:03 <isthmus> Aren’t switch commits conceptually a non-transparent turnstile?
19:38:04 <isthmus> If we define going through a “turnstile” to be migrating outputs generated by a quantum-vulnerable transaction format to a quantum-secured supply, there’s a few ways to do this.
19:38:04 <isthmus> One approach that fits this definition is the Zcash-style turnstile (old shielded pool –> transparent pool –> new shielded pool) 
19:38:04 <isthmus> But another approach is simply making a transaction with switch commitments! If you think about it, that *is* going through the turnstile :D
19:38:04 <isthmus> So if we implement switch commitments in 2025 and then in 2040 cryptographically relevant quantum computers (CRQCs) appear plausible in the near future, pretty much the entire supply (any moneroj that have been moved since 2025) will be post-turnstile. 
19:38:16 <isthmus> Besides avoiding some kind of last-minute turnstile double race conditions (race #1 for devs to develop and deploy the turnstile, race #2 for users to get through it) it has good optics for the intervening timeframe as well.
19:38:17 <isthmus> When people post honest or FUD questions on reddit about CRQCs vs Monero supply, we can say that there’s already an output protection mechanism in the protocol, and to protect your funds just follow these steps:
19:38:17 <isthmus> (1) Make a transaction moving your funds
19:38:17 <isthmus> There. Done. If some long-tail breakthrough in QC tech jeopardizes the integrity of old outputs, your funds are already on the post-quantum side of the line. 
19:40:11 <moneromoooo> Well, we have range proofs. If they can get accumulated, you could maybe do "is sum(these) > threshold". Theoretically.
19:40:57 <moneromoooo> Well, maybe not range proofs in this case, but other crypto ops that do not leak the actual value.
19:42:23 <moneromoooo> Oh. Nevermind. If you could do that, then I suppose an attacker could brute force by making their own proofs and then binary search any existing proof's value.
19:43:30 <UkoeHB> isthmus: yes you definitely need a conversion process that starts when 'risk of DLP solver viability' becomes convincing, but the question is what to do about old funds once you are in the 'danger zone'. Either old funds can't be converted at all, or you have a turnstile that lets some funds through with the idea that at least some honest users will get through before an adversary drains the remaining amount.
19:44:45 <isthmus> That question remains, orthogonal to any mitigation angle, and I don't touch it ):
19:45:46 <isthmus> Nothing we do in the future is going to make v2 transactions post-quantum, sad fact of life
19:46:00 <isthmus> So I tend to be forward-looking
19:47:31 <moneromoooo> If you have to have cleartext amounts, then the answer is obvious: no end date.
19:48:15 <moneromoooo> In that case, the only difference is who gets the coins: you do not stop honest people from getting their coins back at any arbitrary date.
19:48:25 <isthmus> We don't have to have cleartext amount
19:48:33 <moneromoooo> And the attacker can only get the remainder, which does not inflate.
19:48:45 <moneromoooo> Ah, OK.
19:50:25 <isthmus> I think that's the beauty of ElGamal commitments 
19:50:49 <isthmus> No plaintext step
19:51:18 <moneromoooo> That's equivalent to switch commitments in this context ?
19:53:00 * isthmus nods
19:53:18 <isthmus> Or like, ElGamal commitments are a type of switch commitment
19:53:24 <isthmus> afaik
19:53:45 <isthmus> There could be other types(?)
19:54:22 <isthmus> Here's the main reference https://eprint.iacr.org/2017/237.pdf
19:56:06 <isthmus> They are statistically binding but only computationally hiding - so I think the takeaway is that even with a CRQC, to see the amount an adversary would have to crack the hiding. 
19:56:45 <isthmus> (which would be very expensive even if a CRQC could do it in polynomial time, probably not a high priority for an attacker looking to make or steal money)
19:58:14 * isthmus could be wrong about some of this stuff, and invites corrections
19:59:05 <isthmus> Ah this doc might be more relevant and readable https://gist.github.com/tevador/23a84444df2419dd658cba804bf57f1a
20:01:06 <UkoeHB> moneromoooo: post-quantum would have hidden amounts. Option 1) conversion process where you go pre-quantum -> post-quantum with a fixed end date on conversions. Option 2) conversion with a turnstile where you go pre-quantum -> cleartext -> post-quantum and block new conversion txs when cleartext = amount pre-conversion-activation max (i.e. total amount created by block rewards up to the first post-quantum block) (if 
20:01:06 <UkoeHB> using a turnstile, then ALL conversion txs must go through the turnstile so you know when the end condition is met).
20:01:28 <UkoeHB> cleartext amount = pre-conversion-activation max  *
20:01:59 <UkoeHB> so either hard end date, or all users expose amounts when converting
20:03:24 <monerobull[m]1> That would be funny 
20:03:32 <monerobull[m]1> Seeing how many coins are still active 
20:03:56 <UkoeHB> it would be a privacy catastrophe
20:04:18 <monerobull[m]1> But very Anti-Ethos 
20:04:20 <monerobull[m]1> UkoeHB: Yeah
20:05:44 <isthmus> <jokingly> The transaction uniformity improvements of Seraphis are going to knock out most of the Noncesense Research Lab chain analysis arsenal... At least a cleartext turnstile would give me something to analyze! 
20:05:47 <UkoeHB> with elgamal commitments you could theoretically start the conversion process very early, but you need a comprehensive switch protocol (switch commitments by themselves are useless); this is the only existing proposal https://gist.github.com/tevador/23a84444df2419dd658cba804bf57f1a 
20:05:59 <UkoeHB> oh isthmus linked that already
21:26:17 <xmrack[m]> If my understanding is correct an attacker who has a CRQC could forge xmr out of thin air. In this case what benefit would a turnstile have if the entire old supply could be converted into the post quantum xmr. Wouldn’t the attacker drain all the funds and essentially destroy monero due to a single entity controlling a majority of the supply?
21:36:37 <Rucknium[m]> Why would a single entity controlling a large share of the total supply "destroy Monero"? That would only be a problem if Monero were proof-of-stake.
22:03:37 <Lyza> a currency needs to be widely distributed to be useful. it wouldn't break consensus but it would make it functionally hard to use as a currency if you could effectively only buy it from one guy. at that point why not start a new chain tbh
22:09:31 <tevador> "so either hard end date, or all users expose amounts when converting" <- It could also be done by revealing amounts only after the cutoff date since the blinding factor is derived as H("amount" || key), revealing the key proves the amount in the original commitment in a way a CRQC cannot easily fake.
22:15:45 <UkoeHB> tevador: the conversion method question is about old enotes, i.e. enotes without any elgamal or whatever
22:16:29 <tevador> yes, I was talking about RingCT outputs
22:16:48 <tevador> AFAIK wallets derive the blinding factor this way
22:16:49 <UkoeHB> ah
22:17:22 <UkoeHB> a DLP solver could fake the key but then the you'd lose the range, so it could work
22:18:40 <UkoeHB> the problem is old key images can be forged
22:20:27 <UkoeHB> I think?
22:20:59 <UkoeHB> seraphis key images definitely can be, idk about cryptonote
22:21:07 <tevador> RingCT key images cannot be forged, forging only applies to Seraphis.